Bug#285857: dpkg-dev: dpkg-shlibdeps should try adding /usr
Samuel Thibault <firstname.lastname@example.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