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
