Bug#519941: 10.2 Libraries recommends use of /etc/ld.so.conf instead of /etc/ld.so.conf.d
On Mon, Mar 16, 2009 at 07:52:10AM -0700, Steve Langasek wrote:
> 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.
I do not have a strong opinion on this because policy says "for some compelling
reason" and we can imagine setting where rpath does not work.
But anyway, the major offender is libatlas-base-dev:
#cat /etc/ld.so.conf.d/atlas.conf
/usr/lib/atlas
Maybe we should start by reporting a bug to libatlas-base-dev ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: