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

From: Davide Bolcioni (davide_bolcioni_at_[hidden])
Date: 2006-08-12 12:21:42

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.