Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 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.
Actually, objdump is still used to produce the list of immediate
dependencies [ldd will also list indirect dependencies]. As this list
does not include paths, "ldconfig -p" output is used to find them.
This will fail on the Hurd.
So your first alternative ...
> 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).
... should probably be: Don't use ldconfig on the Hurd - assume that
all libraries reside under /lib.
Should this work? In any case, it's not very clean.
The whole issue is symptom of the assumption that the dpkg file
database will hold the one and only location of a particular file. The
Hurd's /usr symlink breaks this assumption. It could be argued, that
this is the Hurd's fault, but there are surely many installations
using similar symlink setups (say, /usr and /home are symlinks to
/big_partition/{usr,home})
Perhaps dpkg itself should be fixed to resolve this. In the above
example, both /usr/bin/man and /big_partition/usr/bin/man should
arguably give the same result when fed to "dpkg -S".
--
Robbe
Attachment:
signature.ng
Description: PGP signature