Re: Bug#519941: 10.2 Libraries recommends use of /etc/ld.so.conf instead of /etc/ld.so.conf.d
On Tue, Mar 17, 2009 at 04:10:27PM +0100, Rafael Laboissiere wrote:
> * Steve Langasek <vorlon@debian.org> [2009-03-16 07:52]:
>
> > 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.
>
> Coincidentally, there has been a followup to Bug#510579 yesterday [1] where
> it is asked to add a /etc/ld.so.conf.d/octave.conf file for making the
> private libraries distributed with octave3.0 available publicly. It seems
> that this would make the life of maintainers of shogun and octave-ruby much
> easier.
>
> What should I do now? Ask the maintainers of those packages to use rpath?
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510579#78
What is the rational for making the library private in the first place ?
Adding a file /etc/ld.so.conf.d/octave.conf is the worse solution:
it does not offer more protection against nameclash than putting
them in /usr/lib.
Cheers,
--
Bill. <ballombe@debian.org>
Reply to: