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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org