Re: [boost] Boost RPM spec file: Take 2

From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-08-14 16:45:51

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/