On Tue, Mar 17, 2009 at 04:10:27PM +0100, Rafael Laboissiere wrote: > * Steve Langasek <[email protected]> [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. <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
