Re: 1.6.0 problems with libguilereadline-v-12 and fix

[Rob Browning]

address@hidden (Paul Jarc) writes:

> I think the right thing is for libltdl to respect *all* of ld.so's
> mechanisms, for the sake of simplicity - you won't have to worry about
> which one is being used when you want to configure something to find
> libraries somewhere.  Any problem that can occur with -rpath can
> already occur with ld.so; any solution for ld.so ought to be usable
> with (the hypothetical fixed) libltdl as well.

That would be fine with me -- frankly I tend to think that runtime
library linking and compile-time library linking should be handled by
the *same* set of people/tools, but we're certainly not there yet :<

> I really don't like such *-config programs.  If package foo links to
> libraries from package bar, I want foo to find bar via a path other
> than bar's installation prefix.  I set up a symlink to bar for foo to
> use.  Then when I install a new version of bar (with its own unique
> installation prefix), I update the symlink (atomically, even) and foo
> finds the new version.

I'm not sure I completely follow.

>> As I recall, the reasoning for this was that from a system
>> integrator's perspective, using an rpath causes major problems.
>> Libraries will need to be moved around from time to time and if you
>> use rpath, you make it impossible to do this
>> transparently/incrementally.
>
> I'm a system integrator too, and I use rpath extensively.  I don't
> move libraries or anything else around post-installation.

I don't fully recall the arguments/rationale, though you could check
the debian-policy or debian-devel archives for more details if you
care (I believe most of this debate pre-dates the debian-policy list).
My impression was that there were times when moving libraries (over
the years) was very hard to avoid, and being able to avoid doing it
en-masse, was somehow a fairly large win.  Perhaps there are some
smart ways to avoid the whole issue, but think that we should be
careful about ignoring this without some investigation.  It's been my
experience (over a long period of time) that debian often has very
good reasons for many of its policies.

Also, what I can say for sure is that unless debian dolicy has
changed, relevant bits of anything that's pacakged for debian will
have to be modified to not set -rpath.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD