Patrick Hartling wrote:
This discussion sort of fizzled out a couple of weeks back, so I thought that I would post a short summary to clarify the goals of the RPM spec file that I posted. First, here is how things are with the way that Red Hat distributes builds of Boost:
* 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 * Does not install multi-threaded variants of Boost libraries * Does not install debug versions of libraries * Does not put headers in a versioned subdirectory of /usr/include * Strips toolset and version from the base library name (libboost_signals.so versus libboost_signals-gcc-1_33_1.so) * Does not allow multiple boost-devel RPMs to be installed in parallel
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
I see 2 issues with the proposed spec. 1) It would install into %{_libdir}, and so potentially conflict with redhat's rpms. I recommend using a different directory. We have /etc/ld.so.conf.d, so this is easy to implement. 2) Unless you fix #1, ldconfig would put libboost_signals.so as a link to redhat's version (because of libboost_signals.so.2).