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

From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-09-08 15:25:53

Neal Becker wrote:
> Patrick Hartling wrote:
> 
>> 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
>>
> 
> I see 2 issues with the proposed spec.
> 
> 1) It would install into %{_libdir}, and so potentially conflict with
> redhat's rpms.

The boost and boost-devel RPMs made by this spec file do not currently
conflict with those made by Red Hat. However, if Red Hat were to start using
fully qualified names on the static and shared libraries, then there would
be a conflict. My main goal with posting this RPM spec file to this list is
for it (or something similar to it) to become the "upstream" spec file for
Boost in hopes that Red Hat and other Linux vendors would follow these
conventions for future releases. Hence, a conflict would, IMHO, be a good
thing in this case.

The "-symlink" packages do conflict with the way that Red Hat currently
packages Boost, and that is why they are optional. The intention is to
provide a way to have a replacement Boost installation that looks like how
Red Hat currently does things--a "just in case" sort of thing to avoid
breaking existing software that is linked against the libraries built by Red
Hat.

> I recommend using a different directory.  We
> have /etc/ld.so.conf.d, so this is easy to implement.

With all due respect, I must admit that I do not like this idea, and that is
why I have not pursued even though you have recommended it previously. Doing
it this way means that people building against Boost have to know to put
-L/usr/lib/xxx in their link line because the Boost libraries in the obvious
place are the "wrong" libraries. For run-time purposes, though, this
approach would be fine.

 -Patrick

> 2) Unless you fix #1, ldconfig would put libboost_signals.so as a link to
> redhat's version (because of libboost_signals.so.2).

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