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

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

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?

> 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.

> Another issue,
> right now, Redhat is using libboost_regex.so.2.  If you run ldconfig, won't
> it change your symlink to point to the highest version number, which might
> not be what you want?

Good point. I need to read up on ldconfig more and understand exactly what
the goal of installing libboost_*.so.2 is.

> I don't know why there is arch_args.  When building on x86_64 you don't need
> to use -m64 - that's the default.  Is this so you can build the i386 rpm on
> an x86_64 host?  Not that it hurts anything.

Yes, that's why that is in there. Back in April when I was making a bunch of
spec files for a customer installation, I needed to be able to target both
i386 and x86_64 from an x86_64 machine. As a result, just about all the spec
files I wrote at that time have this provision.

 -Patrick

-- 
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/