Re: [boost] Boost RPM spec file: Take 2

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-09-08 16:19:07

Patrick Hartling wrote:
> The spec file that I posted does the following:
> 
>    * Allows parallel installations of versioned Boost shared libraries
>      so that boost-1.32.0.rpm, boost-1.33.1.rpm, etc. could all be installed
>      side by side
>    * Installs multi-threaded variants of Boost libraries
>    * Installs both debug and optimized versions of all libraries
>    * Puts headers in a versioned subdirectory of /usr/include
>    * Uses fully qualified library names
>    * Allows multiple boost-devel RPMs to be installed in parallel

OK.

>    * 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