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

From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-08-14 16:08:00

Neal Becker wrote:
> Patrick Hartling wrote:
> 
>> Neal Becker wrote:
>>> Patrick Hartling wrote:

[snip]

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

I was referring to ldconfig being told about directories other than the
trusted set so that users do not have to set/extend $LD_LIBRARY_PATH in
order to find shared libraries that are not in those directories. I know
that that's how it works on FreeBSD. It isn't clear to me from the ldconfig
man page on Enterprise Linux 4 that the Linux version does the same thing,
but I think it must in order for things such as the Qt libraries to be found
without extra effort on the part of the user.

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

Yes, installing boost-symlinks would conflict with the boost RPM that Red
Hat makes. My intention, however, is to replace the Red Hat RPM, rather than
to live alongside it. The -symlinks packages are to provide a means to be
compatible with the naming used by the RPM used by Red Hat.

Ultimately, what I would prefer to see is Red Hat using an installation
scheme for Boost that more closely follows the model that Boost uses, but I
do not know that anyone else necessarily feels that way. Certainly, in the
time that Red Hat has been distributing Boost with Enterprise Linux and
Fedora Core, they must not have gotten many--if any--reports of people
wanting the Boost packaging to change.

 -Patrick

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