Davide Bolcioni wrote:
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).
You are right, this is possible. Using package management to deploy development packages allows for automation that is not necessarily practical when users are putting their dependencies in their home directory on a case-by-case basis. Nevertheless, the benefits of allowing parallel development package installations is perhaps not something that a lot of people want to take advantage of. The real point, however, is that the spec file I posted is that a system-wide installation would use the same conventions as the one that a user puts in his or her home directory. I am used to using Boost in this way, and thus it is my desire to see these conventions used in a system-wide installation. Perhaps my uses of Boost are atypical, but I like using the fully qualified names. Another important aspect of the spec file that I posted is that it does not strip out the multi-threaded versions of the Boost libraries. That, IMO, is a very detrimental aspect of the way that Red Hat has been packaging Boost.
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.
Yes, the non-development Boost packages from Red Hat are installable in parallel. What I failed to make clear the in text quoted above is that the spec file that I posted allows for both the run-time RPM and the development RPM to be installed in parallel whereas the Red Hat approach only allows multiple versions of the run-time RPM to be installed in parallel.
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 links installed by -devel-symlink would point to the version that corresponds with their release. The intention with both of the -symlink packages is to provide compatibility with the way that Red Hat has been doing things thus far, so it should look the same as the way that Red Hat installs Boost in terms of compiler and linker options.
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 ?
We did contact them a little over a year ago about the fact that the multi-threaded versions of the Boost libraries are being stripped from the installation, and we were told that they were not interested in our changes to address that. It is worth trying again to get them to include the multi-threaded libraries. That specific aspect is highly critical for us.
It might be just me, but the above is ... uncustomary.
It is not uncommon for open source software to include a spec file so that people downloading it can use package management for handling the build, installation, and upgrade processes. Whether any given Linux distributor uses a pre-existing spec file as a starting point for their own repackaging of said software is up to them.
Are you trying to follow standard shared library versioning, or do you mean to handcraft what libtool does ?
I mean to follow what Boost does currently because I like that approach. That's just my personal preference, though, and I admit that it took some getting used to when it was first introduced. In particular, I like that the Boost library naming convention is standard across platforms since I regularly switch between three or four operating systems in any given day. Another software tool that I use (that shall remain nameless) uses a different library naming convention between Linux/BSD/Solaris, Mac OS X, and Windows. While symlinks address the Mac OS X differences, my builds have to account for the different usage of the version number in the Windows case. To me, that means extra work and an extra point of failure that doesn't exist for Boost because the build can handle Boost identically on all platforms (assuming proper management of the toolset name differences). -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/