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