dpkg-shlibdeps and /usr/lib, other dpkg stuff
(part 1 of my internal TODO list brain dump)
Hi,
please look at
http://lists.debian.org/debian-dpkg-0102/msg00006.html
it describes an old bug in dpkg-shlibdeps that vanished shortly and is now back.
The issue is that it now uses ldd again to find out not only the name but
also the location of the libraries used by the binary. Because ldd finds
them all under /lib in the Hurd, dpkg-shlibdeps won't be able to find them
via dpkg -S, when they are installed under /usr/lib. There are basically two
approaches to fix it:
1. Don't use ldd on the Hurd at all. It's not needed. Just using objdump as
it was done in a short period before ldd was used again worked fine. The
reason to use ldd on linux doesn't apply for us (it was a libc5
compatibility thing).
2a. When using ldd ad creating the list of libraries to search for, add
LIBPATH and /usr/LIBPATH to the -S option, so either is found. It should
work, although it doesn't feel very clever.
2b. As a variation, find some other way to make sure dpkg finds the
libraries. I haven't made an exhaustive analysis of dpkgs search functions.
Maybe you can add some regex that makes it automatically look in
/usr, too. If you find out, let us know. It might be more acceptable than 2a.
Then the real problem is to find out what the maintainers of dpkg prefer and
get them to incorporate a patch or write one themselve. Looking at the web
archive, my post from 7. Feb (see link above), hasn't triggered any reply,
so either they don't care or they are just busy. In any way, send them a
patch for one or all of the above solutions and keep track of it, to make
sure that the next version really has a proper fix.
This bug is *serious* as it breaks packaging ALL packages that are supposed
to depend on libraries in /usr/lib. The resulting packages will lack the
necessary run time dependencies.
It would be nice if someone would take this over and do all necessary
communication with debian-dpkg on this; or better, use the bug tracking
system.
The following bugs also should be fixed in dpkg, so we can compile from
unchanged source:
#31620: dpkg: don't use hard coded ENOENT
#68783: dpkg should call exec with full path in argv[0]
#76941: dpkg: [hurd] configure gets the architecture wrong
Some of them might be already fixed, some more might get fixed in the next
version. I don't know. It might be a good idea to check them, too.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: