Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote: This could be very bad for the root-system package set. ROOT has libraries named like libMatrix, libPostscript, libPhysics, libMath, and so on - i.e., very general names. For that reason I moved all the packages into the subdirectory /usr/lib/root to not cause possible conflicts. To make this work seamlessly for both the root-system binaries and user code linked against the libraries, I dump a file in /etc/ld.so.conf.d/. For the root-system binaries, there is of course the option to link with RPATH set. However, I believe that the Policy actually forbids this. I see no reason why policy should forbid rpath's for that case. What we don't want is an rpath for /usr/lib. But an rpath for /usr/lib/root would be the right thing to do for libraries/binaries from the root system. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
Kurt Roeckx k...@roeckx.be writes: On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote: This could be very bad for the root-system package set. ROOT has libraries named like libMatrix, libPostscript, libPhysics, libMath, and so on - i.e., very general names. For that reason I moved all the packages into the subdirectory /usr/lib/root to not cause possible conflicts. To make this work seamlessly for both the root-system binaries and user code linked against the libraries, I dump a file in /etc/ld.so.conf.d/. For the root-system binaries, there is of course the option to link with RPATH set. However, I believe that the Policy actually forbids this. I see no reason why policy should forbid rpath's for that case. What we don't want is an rpath for /usr/lib. But an rpath for /usr/lib/root would be the right thing to do for libraries/binaries from the root system. Currently, I don't think Policy says anything about RPATH. It does say: Shared object files (often `.so' files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the `/usr/lib' directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped.[5] Perhaps that's not quite the definition of not public we want? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
On Mon, Jun 22, 2009 at 02:41:09PM +0200, Christian Holm Christensen wrote: I understand this issue, but putting libMatrix in /usr/lib/root avoid file conflict with other package, do not address the problem of library name conflict at run-time. Agreed. Suppose you have packages bar and baz, both of which contain /usr/lib/libfoo.so.1. If bar Conflicts with baz or vice versa, then both of them cannot be installed at the same time, and there will only be one possible /usr/lib/libfoo.so.1 on the system. Now suppose the package gnus comes along, which also provides /usr/lib/libfoo.so.1, then both bar and baz needs to Conflict with gnus, or gnus has to conflict with bar and baz. I guess it is an N! problem. If all of these libfoo.so.1 files implement the same interface, why does someone ever need to have more than one of them installed at a time? In that case, Conflicts: is reasonable; and you can use a mutually agreed-upon virtual package (Conflicts/Replaces/Provides) to solve the N! problem. If they don't implement the same interface, then why are they using the same name? In this case they should solve the conflicts by using distinguished sonames, not merely different paths for the library, to avoid accidental library path collisions. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
On Fri, Jun 26, 2009 at 04:59:26PM +0200, Kurt Roeckx wrote: For the root-system binaries, there is of course the option to link with RPATH set. However, I believe that the Policy actually forbids this. I see no reason why policy should forbid rpath's for that case. For the standard reason that rpath is bad: it breaks when library paths change, as will hopefully happen soon with multiarch. :) What we don't want is an rpath for /usr/lib. But an rpath for /usr/lib/root would be the right thing to do for libraries/binaries from the root system. Yes, it's the least-bad option in this case, in spite of the knock-on problems. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
Hi again, Let me first clear up a confusion: I agree that putting a library in a sub-directory does not disambiguate ld.so searches. If libFoo.so.1 exists in both /usr/lib/bar and /usr/lib/baz and both these directories are in the ld.so search path (one way or another), then there is an ambiguity. On Mon, 2009-06-22 at 12:38 +0200, Bill Allombert wrote: On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote: Hi all, On Fri, 2009-06-19 at 21:25 -0700, Russ Allbery wrote: ... | 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. This could be very bad for the root-system package set. ROOT has libraries named like libMatrix, libPostscript, libPhysics, libMath, and so on - i.e., very general names. For that reason I moved all the packages into the subdirectory /usr/lib/root to not cause possible conflicts. To make this work seamlessly for both the root-system binaries and user code linked against the libraries, I dump a file in /etc/ld.so.conf.d/. I understand this issue, but putting libMatrix in /usr/lib/root avoid file conflict with other package, do not address the problem of library name conflict at run-time. Agreed. Suppose you have packages bar and baz, both of which contain /usr/lib/libfoo.so.1. If bar Conflicts with baz or vice versa, then both of them cannot be installed at the same time, and there will only be one possible /usr/lib/libfoo.so.1 on the system. Now suppose the package gnus comes along, which also provides /usr/lib/libfoo.so.1, then both bar and baz needs to Conflict with gnus, or gnus has to conflict with bar and baz. I guess it is an N! problem. That leaves maintainers no choice but to put libraries in a directory in the general search path - i.e., /usr/lib. Furthermore, it will be up to the maintainers to make sure that he/she figures out if other packages use the same library names and make then `Conflict' against those packages. This could turn out to be quite some work. I cannot see how your scheme avoid such work: your packages still has to conflict with any other that contains libMatrix to avoid a library name conflict. Yes and no. If bar and baz had put libfoo.so.1 in /usr/lib/bar and /usr/lib/baz respectively, one could at least install both packages at the same time without any conflict. If a user needed to use baz's libfoo.so.1, he or she could use an explicit LD_LIBRARY_PATH or LD_PRELOAD to override the cache/system settings of ld.so. In that way, the user at least have a choice. Indeed it make it harder because files conflicts are easier to spot than library name conflict. Agreed. Spotting all possible file conflicts does however require downloading a huge Contents.arch.gz file and grep'ing for all possible names. If this could be automated a little, it would be nice. Now, I agree that the names chosen by upstream ROOT developers are poor. It would have been better to call them something like libRootMatrix, libRootPostscript, and so on (I can lobby for this, but I fear that it will have very little effect). One could argue, that one should simply change the names of the library names in the Debian packages, but several issues makes this undesirable: * ROOT sometimes autoloads libraries in response to user input. This mechanism is partially hard-coded into the sources, and changing the names in Debian packages only would necessitate a lot of patching. * ROOT also sports a kind of Virtual Machine for clusters and Grid computing. One can simply upload a tar-ball with code and an automatically generated Makefile to a cluster, and the code will be built and run on target machine(s). For this to work in a heterogeneous environment like Grid were many types of Linux's, Unix's, and what not machines is supposed to contribute, the names of the libraries must remain the same - since that is assumed by the generated Makefile (which may not be built on Debian at all). I suggest you try the following: Put libRootMatrix in /usr/lib and a symlink /usr/lib/root/libMatrix.so - /usr/lib/libRootMatrix.so This way it will be possible to do gcc -L/usr/lib/root/ -lMatrix as it is done currently. Ah, but that does not solve the issue. If you do this, the so-name referenced in the application/shared library will be libRootMatrix which may not exist on another machine. Kind of tricky this is. Apart from that, making symlinks all over the place isn't really that nice (I know I do make a lot already - but I'm trying to convince upstream a better solution). Note that
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
On Mon, Jun 22, 2009 at 02:41:09PM +0200, Christian Holm Christensen wrote: Yes and no. If bar and baz had put libfoo.so.1 in /usr/lib/bar and /usr/lib/baz respectively, one could at least install both packages at the same time without any conflict. If a user needed to use baz's libfoo.so.1, he or she could use an explicit LD_LIBRARY_PATH or LD_PRELOAD to override the cache/system settings of ld.so. In that way, the user at least have a choice. Agreed, though if both packages add /usr/lib/bar(baz) to ld.so at installation times and try to run some programs, they might fail to install. Indeed it make it harder because files conflicts are easier to spot than library name conflict. Agreed. Spotting all possible file conflicts does however require downloading a huge Contents.arch.gz file and grep'ing for all possible names. If this could be automated a little, it would be nice. I does this check at times (for all the archive) and report bugs... At least dpkg will report an error when this occurs. Now, I agree that the names chosen by upstream ROOT developers are poor. It would have been better to call them something like libRootMatrix, libRootPostscript, and so on (I can lobby for this, but I fear that it will have very little effect). One could argue, that one should simply change the names of the library names in the Debian packages, but several issues makes this undesirable: * ROOT sometimes autoloads libraries in response to user input. This mechanism is partially hard-coded into the sources, and changing the names in Debian packages only would necessitate a lot of patching. * ROOT also sports a kind of Virtual Machine for clusters and Grid computing. One can simply upload a tar-ball with code and an automatically generated Makefile to a cluster, and the code will be built and run on target machine(s). For this to work in a heterogeneous environment like Grid were many types of Linux's, Unix's, and what not machines is supposed to contribute, the names of the libraries must remain the same - since that is assumed by the generated Makefile (which may not be built on Debian at all). I suggest you try the following: Put libRootMatrix in /usr/lib and a symlink /usr/lib/root/libMatrix.so - /usr/lib/libRootMatrix.so This way it will be possible to do gcc -L/usr/lib/root/ -lMatrix as it is done currently. Ah, but that does not solve the issue. If you do this, the so-name referenced in the application/shared library will be libRootMatrix which may not exist on another machine. Kind of tricky this is. Apart from that, making symlinks all over the place isn't really that nice (I know I do make a lot already - but I'm trying to convince upstream a better solution). I agree, though I think my solution adresses your two * points above. Do you really have strong binary compatibility requirement between a Debian machine and a non-Debian one ? Given the mess root shared libraries are, this seems a difficult proposition. I hope I explained adequately why root-system-common dumps a file in /etc/ld.so.conf.d - if not, let me know. I do not know. Maybe you could explain in what kind of situation a conflict is fully prevented by your scheme. It isn't - as I said. For the next set of ROOT packages, I will put all libraries in /usr/lib directly, while I will leave plug-ins in /usr/lib/root/X.Y/ (they are not meant to be public even though many ROOT users think they are). As far as I can tell no other packages supply any library name that conflicts with the ROOT library names at the moment, so I guess I'll be stacking a claim on that namespace :-) I agree it will be better than the current arrangement. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
Hi all, On Fri, 2009-06-19 at 21:25 -0700, Russ Allbery wrote: In Policy Bug#519941, it was proposed to remove the Policy permission for packages to modify ld.so.conf in exceptional circumstances. The implication would be that all packages which do this will need to either move their libraries into a standard library directory like /usr/lib if they're really intended to be public or compile with an RPATH setting. Permission for packages to modify the global library search order to include a non-standard directory would be removed. The rationale as stated by Steve Langasek: | 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. This could be very bad for the root-system package set. ROOT has libraries named like libMatrix, libPostscript, libPhysics, libMath, and so on - i.e., very general names. For that reason I moved all the packages into the subdirectory /usr/lib/root to not cause possible conflicts. To make this work seamlessly for both the root-system binaries and user code linked against the libraries, I dump a file in /etc/ld.so.conf.d/. For the root-system binaries, there is of course the option to link with RPATH set. However, I believe that the Policy actually forbids this. That leaves maintainers no choice but to put libraries in a directory in the general search path - i.e., /usr/lib. Furthermore, it will be up to the maintainers to make sure that he/she figures out if other packages use the same library names and make then `Conflict' against those packages. This could turn out to be quite some work. Now, I agree that the names chosen by upstream ROOT developers are poor. It would have been better to call them something like libRootMatrix, libRootPostscript, and so on (I can lobby for this, but I fear that it will have very little effect). One could argue, that one should simply change the names of the library names in the Debian packages, but several issues makes this undesirable: * ROOT sometimes autoloads libraries in response to user input. This mechanism is partially hard-coded into the sources, and changing the names in Debian packages only would necessitate a lot of patching. * ROOT also sports a kind of Virtual Machine for clusters and Grid computing. One can simply upload a tar-ball with code and an automatically generated Makefile to a cluster, and the code will be built and run on target machine(s). For this to work in a heterogeneous environment like Grid were many types of Linux's, Unix's, and what not machines is supposed to contribute, the names of the libraries must remain the same - since that is assumed by the generated Makefile (which may not be built on Debian at all). Note that using a separate directory and modifying ld.so.conf does not usefully resolve name conflicts, since all the libraries end up on the same global search path anyway and one still has to use RPATH to select which of two conflictingly-named libraries one wants to load. This is, of course, a good point, and the only proper solution to this is of course to make sure that every single library out there has a globally unique name (or some other kind of Magic identifier). However, in the face of `difficult' packages like ROOT or legacy stuff it might be good to allow for using specific sub-directories. Given that it is only a few packages that does this, it may not be so bad after all. Also, since ld.so looks for the so-name which _must_ (according to Policy) contain an interface number it seems unlikely (but not impossible) that two libraries with the same basename but in two different directories, has the same so-name. This has already recieved the support of six Debian Developers, which is more than enough to make this change in Policy. However, due to the broader effects, I wanted to make sure that people were aware of this discussion and had a chance to review and weigh in. This was my 2 €¢ :-) I'm also copying the maintainers of all packages that apt-file says include files in /etc/ld.so.conf.d except for libc6 and friends. I have not
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote: Hi all, On Fri, 2009-06-19 at 21:25 -0700, Russ Allbery wrote: In Policy Bug#519941, it was proposed to remove the Policy permission for packages to modify ld.so.conf in exceptional circumstances. The implication would be that all packages which do this will need to either move their libraries into a standard library directory like /usr/lib if they're really intended to be public or compile with an RPATH setting. Permission for packages to modify the global library search order to include a non-standard directory would be removed. The rationale as stated by Steve Langasek: | 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. This could be very bad for the root-system package set. ROOT has libraries named like libMatrix, libPostscript, libPhysics, libMath, and so on - i.e., very general names. For that reason I moved all the packages into the subdirectory /usr/lib/root to not cause possible conflicts. To make this work seamlessly for both the root-system binaries and user code linked against the libraries, I dump a file in /etc/ld.so.conf.d/. I understand this issue, but putting libMatrix in /usr/lib/root avoid file conflict with other package, do not address the problem of library name conflict at run-time. That leaves maintainers no choice but to put libraries in a directory in the general search path - i.e., /usr/lib. Furthermore, it will be up to the maintainers to make sure that he/she figures out if other packages use the same library names and make then `Conflict' against those packages. This could turn out to be quite some work. I cannot see how your scheme avoid such work: your packages still has to conflict with any other that contains libMatrix to avoid a library name conflict. Indeed it make it harder because files conflicts are easier to spot than library name conflict. Now, I agree that the names chosen by upstream ROOT developers are poor. It would have been better to call them something like libRootMatrix, libRootPostscript, and so on (I can lobby for this, but I fear that it will have very little effect). One could argue, that one should simply change the names of the library names in the Debian packages, but several issues makes this undesirable: * ROOT sometimes autoloads libraries in response to user input. This mechanism is partially hard-coded into the sources, and changing the names in Debian packages only would necessitate a lot of patching. * ROOT also sports a kind of Virtual Machine for clusters and Grid computing. One can simply upload a tar-ball with code and an automatically generated Makefile to a cluster, and the code will be built and run on target machine(s). For this to work in a heterogeneous environment like Grid were many types of Linux's, Unix's, and what not machines is supposed to contribute, the names of the libraries must remain the same - since that is assumed by the generated Makefile (which may not be built on Debian at all). I suggest you try the following: Put libRootMatrix in /usr/lib and a symlink /usr/lib/root/libMatrix.so - /usr/lib/libRootMatrix.so This way it will be possible to do gcc -L/usr/lib/root/ -lMatrix as it is done currently. Note that using a separate directory and modifying ld.so.conf does not usefully resolve name conflicts, since all the libraries end up on the same global search path anyway and one still has to use RPATH to select which of two conflictingly-named libraries one wants to load. This is, of course, a good point, and the only proper solution to this is of course to make sure that every single library out there has a globally unique name (or some other kind of Magic identifier). But this makes your attempt at avoiding conflict quite futile. However, in the face of `difficult' packages like ROOT or legacy stuff it might be good to allow for using specific sub-directories. Given that it is only a few packages that does this, it may
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
Christian Holm Christensen ch...@nbi.dk writes: This could be very bad for the root-system package set. ROOT has libraries named like libMatrix, libPostscript, libPhysics, libMath, and so on - i.e., very general names. For that reason I moved all the packages into the subdirectory /usr/lib/root to not cause possible conflicts. To make this work seamlessly for both the root-system binaries and user code linked against the libraries, I dump a file in /etc/ld.so.conf.d/. For the root-system binaries, there is of course the option to link with RPATH set. However, I believe that the Policy actually forbids this. That leaves maintainers no choice but to put libraries in a directory in the general search path - i.e., /usr/lib. Which is what you already did by adding the directory to ld.so.conf, no? Furthermore, it will be up to the maintainers to make sure that he/she figures out if other packages use the same library names and make then `Conflict' against those packages. This could turn out to be quite some work. Except that moving them to a different directory doesn't really avoid this if you have a fully conflicting library with the same version. If you installed both root-system and another library with the same name at the same time now, you'd get one or the other depending on the ld.so.conf order, leading to unpredictable results, segfaults, and so forth. dpkg refusing to install both at the same time is actually cleaner, I think. It also shouldn't be that much work to use apt-file to watch for conflicting packages. You should be able to set up a script that uses apt-file and runs once a month or so to look for new conflicts. This is, of course, a good point, and the only proper solution to this is of course to make sure that every single library out there has a globally unique name (or some other kind of Magic identifier). However, in the face of `difficult' packages like ROOT or legacy stuff it might be good to allow for using specific sub-directories. Given that it is only a few packages that does this, it may not be so bad after all. Also, since ld.so looks for the so-name which _must_ (according to Policy) contain an interface number it seems unlikely (but not impossible) that two libraries with the same basename but in two different directories, has the same so-name. The same thing applies to libraries installed in the same directory, such as both installed in /usr/lib, although the dev packages would have to conflict. Heimdal and libkrb5-3 both install a /usr/lib/libkrb5 shared library, for instance, but with different SONAMEs, so just the development packages have to conflict. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
I demand that Bill Allombert may or may not have written...
On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote:
On Fri, 2009-06-19 at 21:25 -0700, Russ Allbery wrote:
[snip]
ROOT has libraries named like libMatrix, libPostscript, libPhysics,
libMath, and so on - i.e., very general names. For that reason I moved
all the packages into the subdirectory /usr/lib/root to not cause
possible conflicts. To make this work seamlessly for both the
root-system binaries and user code linked against the libraries, I dump a
file in /etc/ld.so.conf.d/.
I understand this issue, but putting libMatrix in /usr/lib/root avoid file
conflict with other package, do not address the problem of library name
conflict at run-time.
Perhaps this?
* Install the binaries in /usr/lib/root.
* Provide wrappers such as the following in /usr/bin:
#! /bin/sh -e
export LD_LIBRARY_PATH=/usr/lib/root${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH}
exec /usr/lib/root/$(basename $0) $@
[snip]
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| Debian GNU/Linux | or ds,demon,co,uk| Northumberland | Army
| + RIPA NOTICE: NO CONSENT GIVEN FOR INTERCEPTION OF MESSAGE TRANSMISSION
The only way to make something foolproof is to keep it away from fools.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
Darren Salt li...@youmustbejoking.demon.co.uk writes:
Perhaps this?
* Install the binaries in /usr/lib/root.
* Provide wrappers such as the following in /usr/bin:
#! /bin/sh -e
export LD_LIBRARY_PATH=/usr/lib/root${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH}
exec /usr/lib/root/$(basename $0) $@
It's generally better to just set RPATH when building the binaries for
that case.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519941: Remove Policy permission for packages to modify ld.so.conf
In Policy Bug#519941, it was proposed to remove the Policy permission for packages to modify ld.so.conf in exceptional circumstances. The implication would be that all packages which do this will need to either move their libraries into a standard library directory like /usr/lib if they're really intended to be public or compile with an RPATH setting. Permission for packages to modify the global library search order to include a non-standard directory would be removed. The rationale as stated by Steve Langasek: | 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. Note that using a separate directory and modifying ld.so.conf does not usefully resolve name conflicts, since all the libraries end up on the same global search path anyway and one still has to use RPATH to select which of two conflictingly-named libraries one wants to load. This has already recieved the support of six Debian Developers, which is more than enough to make this change in Policy. However, due to the broader effects, I wanted to make sure that people were aware of this discussion and had a chance to review and weigh in. I'm also copying the maintainers of all packages that apt-file says include files in /etc/ld.so.conf.d except for libc6 and friends. I have not individually checked these packages to understand why they include an ld.so.conf.d fragment, and this doesn't include any packages that modify /etc/ld.so.conf. This is the proposed modification to Policy: --- a/policy.sgml +++ b/policy.sgml @@ -7011,17 +7011,6 @@ strip --strip-unneeded varyour-lib/var /p p - Packages containing shared libraries that may be linked to - by other packages' binaries, but which for some - emcompelling/em reason can not be installed in - file/usr/lib/file directory, may install the shared library - files in subdirectories of the file/usr/lib/file directory, - in which case they should arrange to add that directory in - file/etc/ld.so.conf/file in the package's post-installation - script, and remove it in the package's post-removal script. - /p - - p An ever increasing number of packages are using prgnlibtool/prgn to do their linking. The latest GNU libtools (= 1.3a) can take advantage of the metadata in the Please copy 519...@bugs.debian.org on all discussion. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
