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

From: Neal Becker (ndbecker2_at_[hidden])
Date: 2006-08-10 09:40:35

Patrick Hartling wrote:

> Neal Becker wrote:
>> Patrick Hartling wrote:
>> 
>>> Several weeks ago, I posted an RPM spec file for Boost that I was hoping
>>> to see used as the "upstream" spec file for Boost installations on
>>> RPM-based Linux distributions. If nothing else, having it serve as a
>>> model to Linux distributors would be great, too. I have attached an
>>> updated version of that spec file that I feel is an improvement to the
>>> earlier version.
>>>
>>> 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. The attached RPM spec file leverages that in a way that I
>>> see as being very valuable.
>>>
>>> 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. 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.
>>>
>>> Since there are likely to be many users who are expecting Boost to be
>>> installed using the Red Hat RPM, I have added some compatibility bits in
>>> the form of two extra RPMs called boost-symlinks and
>>> boost-devel-symlinks. The first installs symlinks for the Boost
>>> libraries named using Red Hat's stripped down convention (with the
>>> version number after the .so part of the name). 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.
>>>
>>> Comments?
>>>
>>>  -Patrick
>>>
>>>
>> I have taken some similar approach.  I put includes in a parallel dir,
>> but I
>> also put libs in a parallel dir.  This prevents any conflicts.  If you do
>> this, you don't need a seperate symlink package, right?
> 
> Yes, that is true. I didn't notice that detail in your spec file. That is
> certainly an interesting idea since ldconfig should take care of extending
> the default search path, right?

Not sure what you mean by ldconfig extending search path.  ldconfig can be
told about new search path.  In recent fedoras, we have /etc/ld.so.conf.d. 
All you need to do is have your rpm drop a file in this directory, and
search path is extended.

>> Since Redhat will produce %{_libdir}/libboost_regex.so.1.33.1
>> and so might you, don't you have to use a different libdir?
> 
> My intention was to produce RPMs that can be used in place of those from
> Red Hat while still providing the same file names and directory structure
> for people who want that. Personally, I want to use the fully qualified
> library names because it facilitates parallel installations so well. This
> is important for my company's goals since we want to install long-lived
> software on customers' computers and be able to make easy patches/upgrades
> along the way. If the focus changes such that this spec file is for making
> a Boost installation that can live along side the one made by Red Hat,
> then several aspects of the spec file would change.

So, the suggestion is that redhat will produce
e.g., %{_libdir}/libboost_regex.so.1.33.1 and that the proposed package
will also produce %{_libdir}/libboost_regex.so.1.33.1, so they will
conflict?  Maybe I misunderstood.  AFAIK, a parallel install is the way to
go.