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:

> Le jeu 16 déc 2004 à 02:40:00 +0100, Goswin von Brederlow a tapoté sur son clavier :
>
>> > 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 hurd's symlink is as much hardcoded as this.
>
>> The real fix would be to check if the used library and the file dpkg
>> knows canonify into the same file.
>
> But how can this be done, provided this:
>
>> > 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).
>
>  ?
>
> Since any library which gets installed in /usr/lib will actually be
> installed in /lib, ldd will always return that the used library is
> /lib/libbar.so, not /usr/lib, while packages will always install them
> in /usr/lib (really hard to fix in *every* package !), that can't be
> fixed provided the hurd's symlink.

Say on an i386 system the /usr partition gets too full and the admin
decides to move /usr/lib around to somewhere else.

>> By the way, the same problem arises if you link /usr to /mnt/space/usr
>> or any other linking.
>
> No, because unless you add /mnt/space/usr to LD_LIBRARY_PATH, ldd will
> correctly find used librairies in /usr/lib (and this matches dpkg's
> idea), there's no possible confusion here.

That sounds right but on amd64 we did have problems with the lib64
link, libraries showing up as /usr/lib/libfoobar.so instead of
/usr/lib64/libfoobar.so as dpkg thought. All I'm saying is that I've
seen this problem before and not in the hurd way. Canonify is the more
general solution.

> Regards,
> Samuel

MfG
        Goswin