Bug#527537: Broken library search paths

[Goswin von Brederlow <goswin-v-b@web.de>]

Arthur Loiret <aloiret@debian.org> writes:

> The missing dir separator has been added, the fix is in our svn. Now a
> few comments about your bug report:
>
> 2009/5/8, Goswin Brederlow <goswin-v-b@web.de>:
>> # Broken path. Missing a '/'?
>
> Yes, fixed.
>
>> * Duplicate entry after canonicalize
>
> Not an issue.
>
>> ! Path for the wrong target
>
> Not an issue as long as the 32-bit paths are before the other paths.

Unless one is missing a library and the other isn't. Esspecially in
the case of glibc and uclibc based libs where I think the object
format is the same and the wrong lib would get linked in.

But it is not critical as long as, as you say, the order is right.

>> "/lib/x86_64-linux-gnu" is missing.
>> "/lib/i486-linux-gnu" is missing.
>
> No they're not. We have never wanted them.

Then why is /lib in there? Currently I see the following compile time
libs in /lib:

xfslibs-dev_2.9.8-1lenny1: /lib/libhandle.so -> libhandle.so.1
xfslibs-dev_2.10.2-2: /lib/libhandle.so -> libhandle.so.1
libdm0-dev_2.2.8-1: /lib/libdm.so -> libdm.so.0
libcap-dev_1.10-14: /lib/libcap.so -> libcap.so.1
libcap2-dev_2.11-2: /lib/libcap.so -> libcap.so.2
libcap-dev_2.16-5: /lib/libcap.so -> libcap.so.2
libupsclient1-dev_2.2.2-10: /lib/libupsclient.so -> libupsclient.so.1.0.0
libupsclient1-dev_2.4.1-2: /lib/libupsclient.so -> libupsclient.so.1.0.0
libacl1-dev_2.2.47-2: /lib/libacl.so -> libacl.so.1
libattr1-dev_2.4.43-2: /lib/libattr.so -> libattr.so.1
libgpib0-dev_3.2.11-2: /lib/libgpib.so -> libgpib.so.0.1.5
libgpib0-dev_3.2.11-1: /lib/libgpib.so -> libgpib.so.0.1.5
iptables-dev_1.4.3.2-2: /lib/libxtables.so -> libxtables.so.2.0.0
iptables-dev_1.4.3.2-2: /lib/libiptc.so -> libiptc.so.0.0.0
iptables-dev_1.4.2-6: /lib/libxtables.so -> libxtables.so.0.0.0
iptables-dev_1.4.3.2-1: /lib/libxtables.so -> libxtables.so.2.0.0
iptables-dev_1.4.3.2-1: /lib/libiptc.so -> libiptc.so.0.0.0
libnss-lwres_0.93-4.2+b1: /lib/libnss_lwres.so -> libnss_lwres.so.2.0.0
libnss-lwres_0.93-5: /lib/libnss_lwres.so -> libnss_lwres.so.2.0.0
libsplashy1-dev_0.3.13-5: /lib/libsplashy.so -> libsplashy.so.1.0.0
libsplashy1-dev_0.3.13-5: /lib/libsplashycnf.so -> libsplashycnf.so.1.0.0
libsplashy1-dev_0.3.13-4: /lib/libsplashy.so -> libsplashy.so.1.0.0
libsplashy1-dev_0.3.13-4: /lib/libsplashycnf.so -> libsplashycnf.so.1.0.0
libsplashy1-dev_0.3.13-3: /lib/libsplashy.so -> libsplashy.so.1.0.0
libsplashy1-dev_0.3.13-3: /lib/libsplashycnf.so -> libsplashycnf.so.1.0.0
libusplash-dev_0.5.19-3: /lib/libusplash.so -> libusplash.so.0
libbrlapi-dev_3.10~r3724-1+lenny1: /lib/libbrlapi.so -> libbrlapi.so.0.5.1
libbrlapi-dev_3.10~r3724-1.1: /lib/libbrlapi.so -> libbrlapi.so.0.5.1

Should they all be moved to /usr/lib/ or /usr/lib/x86_64-linux-gnu for
multiarch? Currently they would end up in /lib/x86_64-linux-gnu.

It is a really small set (13 packages) compared to the number of libs
in Debian so moving them should be easy.

MfG
        Goswin