Bug#285857: dpkg-dev: dpkg-shlibdeps should try adding /usr

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:

> Package: dpkg-dev
> Version: 1.10.25
> Severity: normal
> Tags: patch
>
>
> Hi,
>
> The hurd-i386 port defines /usr to be a symlink to '.', i.e. libraries
> that are installed in /usr/lib by dpkg actually are installed in /lib
> (and also appear in /usr/lib). dpkg-shlibdeps then fails to find
> packages corresponding to libraries: for instance, say a binary foo
> in package foo uses libbar.so, provided in /usr/lib/libbar.so by
> the libbar package. ldd will give /lib/libbar.so as shared library
> dependancy information, since that's the first place where it can
> be found. And then dpkg --search /lib/libbar.so reports nothing,
> of course, so that dpkg-shlibdeps won't find out that it actually
> belongs to package libbar.
>
> And adding /usr/lib in the LD_LIBRARY_PATH to get it found out first is
> no good idea since that's the libc that is found in /usr/lib instead of
> /lib, for instance...
>
> Here is a patch to let dpkg-shlibdeps also try adding /usr to library
> paths, which really works nicely:

Bad idea. That is just too hardcoded.

The real fix would be to check if the used library and the file dpkg
knows canonify into the same file.

By the way, the same problem arises if you link /usr to /mnt/space/usr
or any other linking.

MfG
        Goswin