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