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 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 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. > > 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. 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
