Patrick Hartling wrote:
The philosophy behind this new spec file is to be as true as possible to what I understand to be a "normal" Boost installation. I realize that users are afforded many ways to customize their Boost installation through different build-time options. Without doing any build customization, however, a Boost installation has single- and multi-threaded variants of libraries, both static and dynamic, that are named based on the toolset used for building and the Boost version number. Furthermore, the headers are installed in a versioned subdirectory. All of this allows parallel installations of different Boost build variants, and I see that as an extremely powerful capability.
I am mostly a lurker on the Boost list, but the above strikes me as odd. The point of installing a library as an RPM package is to satisfy the dependencies for other installed packages, not to make it available to a software developer. Similarly, the corresponding development package is intended to facilitate the packaging by making sure that the source code gets compiled against the same set of choices which are embedded in the RPM package found on the destination host, so that saying "Requires: boost" in the .spec file has a good chance of working. Software developers can readily install multiple versions in their home directories, or even dedicate seperate accounts to separate versions, so I am not seeing the benefit of the above (except for developers using RPM to manage software in their home directory: an interesting thought).
Relative to the Boost RPM distributed for use on Red Hat distributions of Linux (I do not have experience with pre-packaged versions of Boost from other Linux distribution vendors, so I cannot comment on how they do things), this RPM spec file has the following benefits:
* Allows parallel installations of multiple Boost releases (both the run-time RPM and the developer RPM) * Installs single- and multi-threaded builds of libraries
The spec file that Red Hat uses for building Boost RPMs removes the toolset name and the version information from the base name of the library, and it only installs the single-threaded build of each library. For reasons that are not yet clear to me, an additional symlink is created for each Boost shared library named libboost_<libname>.so.2 that points to libboost_<libname>.so.1.33.1.
I guess this is meant to address the "broken promise" problem: if boost.so.1.33 were not fully ABI compatible with boost.so.1.32, it was necessary to label boost.so.1.33 with a SONAME of boost.so.2 so that applications linked against boost.so.1.32 would not attempt to load it and crash. By the way, this leads me to think (I have not checked) that the packages are either (a) already *are* installable side by side, if the SONAME is different, or (b) must be prevented from being available at the same time, if the SONAME is the same.
This prevents multiple parallel run-time installations. Multiple developer installations are prevented by the removal of the version information from the base library name and by the fact that the headers are placed in /usr/include/boost instead of in /usr/include/boost-1_33_1/boost.
If multiple developer installations exist, where does the development symlink point to ? More to the point: if it does not point to the library provided by Red Hat, I am in trouble.
The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now.
Did you consider contacting the people at Red Hat managing the packaging of Boost ? It might be just me, but the above is ... uncustomary. Are you trying to follow standard shared library versioning, or do you mean to handcraft what libtool does ? Davide Bolcioni -- There is no place like /home.