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