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

From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-09-08 10:13:52

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

Basically, the spec file that I posted follows what I understand to be the
"normal" way of installing Boost. In other words, the boost and boost-devel
RPMs created by this spec file provide a Boost installation as it would look
after running 'bjam install --prefix=/usr'.

Are there other thoughts on this topic other than what was discussed
previously on this thread (much of which is below), or is this approach to
installing Boost not how people normally want to operate on Linux?

 -Patrick

Patrick Hartling wrote:
> 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 L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/