Greetings, just my 2 cents ... Patrick Hartling wrote:
* Installs multi-threaded variants of Boost libraries * Installs both debug and optimized versions of all libraries
I guess linking an executable built against the multi-threaded library with a .so built against the single-threaded library is somehow detected ?
* Allows multiple boost-devel RPMs to be installed in parallel
I see this as somewhat dangerous. Consider this bug: http://lists.debian.org/debian-devel/2005/09/msg00657.html which occurred because code linked against libstdc++5 linked another library which was itself linked against libstdc++6, throwing any ODR assumptions by either compiler into la-la land. Although stuff such as linker namespaces and visibility are meant to address that, they introduce platform- and linker-specific magic which should be weighted against the simple approach: an executable and all its libraries, recursively, constitute a single process image so everything must be built against the exact same set of headers and libraries. Now, having a development environment where exactly one development package can be installed helps with the above simple approach: just rebuild all .src.rpms in this development environment. If you have to build for multiple targets, look into chroots, virtual machines, or stuff like mock http://fedoraproject.org/wiki/Legacy/Mock instead of relying on developers getting it manually correct every single time (OK, in their Makefiles). Having the development package chosen once, by the distributor when the distribution is first released, also helps different developers to agree on which development package to use.
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'.
This is fine for a single developer in his $HOME, but I am unconvinced of its merits in a production system under package management. Thank your for your consideration, Davide Bolcioni -- There is no place like /home.