Henrique de Moraes Holschuh writes ("Re: [Proposal] binaries must not have
rpath outside /usr/lib/<dir>/"):
> On Fri, 02 Dec 2005, Ian Jackson wrote:
> > > Indeed, rpath is only acceptable for:
> > > 1. dynamically loaded modules/plugins
> > > 2. libraries that must live outside of ld.so directories
> >
> > And these things might reasonably be searched for in
> > /usr/local/lib/foo as well as /usr/lib/foo.
>
> rpath is for the canon location of a library. If someone wants something
> searched, he puts it (in fact, I guess we already do for him) in ld.so.conf.
Let us suppose there is a program frobnicate which can load plugin
modules, with a stable and published ABI.
Now the Debian frobnicate package will come with a pile of modules in
/usr/lib/frobnicate, named /usr/lib/frobnicate/modules/frictive.so,
/usr/lib/frobnicate/modules/smooth.so, and so on. Typically these
might be loaded because /etc/frobnicate/frobnicate.conf says `module
frictive' or some such.
A sensible way to arrange for this to work might be for
/usr/bin/frobnicate's rpath to specify /usr/lib/frobnicate/modules.
That way frobnicate can load `frictive' without having to specify the
path.
If it's done like this then /usr/local/lib/frobnicate/modules should
also be in the rpath (and it should be ahead of /usr/lib/frobnicate),
so that the sysadmin's /usr/local/lib/frobnicate/lumpy.so gets loaded
with `module lumpy' without frobnicate-loadmodule.c having to
implement a path-searching function (since the dynamic linker will do
that for us).
> There is no legal, acceptable or even remotely sane reason for a rpath
> pointing to /usr/local/* *IN SOMETHING PACKAGED BY DEBIAN*.
Please don't shout. I heard you the first time.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
