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 "Conflict"s 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 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.
Agreed, as I said above.
> > 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 :-)
Yours,
--
___ | Christian Holm Christensen
|_| | -------------------------------------------------------------
| | Address: Sankt Hansgade 23, 4 Phone: (+45) 35 35 96 91
_| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91
_| Denmark Office: (+45) 353 25 447
____| Email: cholm@nbi.dk Web: http://cern.ch/cholm
| |
Reply to: