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 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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: