Boost logo

Boost :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-09-20 12:19:28


I know I'm quoting most of the original message... But this is a ping.
Patrick you there?

Rene Rivera was being inquisitive:
> Patrick Hartling wrote:
>> The spec file that I posted does the following:
>>
>> * Provides compatibility with (current) Red Hat conventions using
>> optional "-symlink" packages, the use of which would conflict with
>> Boost RPMs provided by Red Hat and would prevent the ability to
>> install multiple boost-devel RPMs in parallel
>
> Are those different from the synlinks the "bjam install" does? Does your
> RPM put in the symlinks "bjam install" produces?
>
>> Basically, the spec file that I posted follows what I understand to be the
>> "normal" way of installing Boost. In other words, the boost and boost-devel
>> RPMs created by this spec file provide a Boost installation as it would look
>> after running 'bjam install --prefix=/usr'.
>>
>> Are there other thoughts on this topic other than what was discussed
>> previously on this thread (much of which is below), or is this approach to
>> installing Boost not how people normally want to operate on Linux?
>
> I personally like it, but then again I came up with the current install
> scheme, so I'm biased :-) A few future and integration questions...
>
> Have you tried packaging the 1.34 branch?
>
> Is it buildable if one doesn't have admin privileges? I'm asking because
> making the RPM during a release cycle would be much easier if we can use
> the SF compile farm machines instead of relying on personal setups.
>
> It's been suggested a few times that we should move Boost towards a
> non-monolithic distribution model. Which means that we would want to
> have individual RPMs for the various libraries. Which I guess also means
> that a top level Boost RPM would be only a reference to the other
> version specific RPMs for the libraries. Now...
>
> Do you see any problems that your RPM would create if we do move in that
> direction?
>
> If Boost does provide an RPM, we would need someone to actively maintain
> it. Are you volunteering yourself to do this maintenance? Note, it would
> not just be editing the RPM script(s) but also witting documentation,
> specifically for the release manager to use in building the RPMs.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk