Re: [Proposal] binaries must not have rpath outside /usr/lib/<dir>/

[Ian Jackson <ian@davenant.greenend.org.uk>]

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.