Bug#519941: 10.2 Libraries recommends use of /etc/ld.so.conf instead of /etc/ld.so.conf.d

[Adeodato Simó <dato@net.com.org.es>]

* Steve Langasek [Mon, 16 Mar 2009 07:52:10 -0700]:

> On Mon, Mar 16, 2009 at 11:40:36AM +0100, Goswin von Brederlow wrote:
> > Debian policy 10.2 Libraries says:

> > | Packages containing shared libraries that may be linked to by other
> > | packages' binaries, but which for some compelling reason can not be
> > | installed in /usr/lib directory, may install the shared library files
> > | in subdirectories of the /usr/lib directory, in which case they should
> > | arrange to add that directory in /etc/ld.so.conf in the package's
> > | post-installation script, and remove it in the package's post-removal
> > | script.

> > I believe this should be changed to dropping a file into
> > /etc/ld.so.conf.d instead. Giving a policy for the filename might be a
> > good idea too so there won't be conflicts. How about
> > /etc/ld.so.conf/<package>.conf?

> This recommendation needs to be elminated entirely.  It is *not* ok for
> packages that provide libraries to stick extra linker paths in the global
> configuration, whether by modifying ld.so.conf or by adding to
> /etc/ld.so.conf.d.  Either the libraries provided by the packages are meant
> to be public, in which case they should be installed to the standard library
> path instead of needlessly adding another directory that's going to be
> globally visible anyway; or they should not, and the cooperating packages
> should use rpath instead.

> Use of rpath should still be discouraged, but if someone is bound and
> determined to violate the FHS with their library paths in order to have
> private libraries, they should make them really private with rpath instead
> of using this "compromise" solution that takes the worst of each approach.

+1

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai