I noticed this first with dpkg-shlibdeps,
it breaks and is worthless for anything linked to a file of the form

/usr//lib/lib.so

note the double slash

This is quite annoying because if you have files linked in like this, they
won't get included as a dependency (arguably linking them with filenames
like this is incorrect)

e.g.

[SYSTEM] % dpkg-shlibdeps -Tsomefile /usr/bin/noteedit
dpkg-shlibdeps: warning: could not find any packages for
/usr//lib/libnoteedit.so.1 (libnoteedit.so.1)
dpkg-shlibdeps: warning: unable to find dependency information for shared
library libnoteedit (soname 1, path /usr//lib/libnoteedit.so.1, dependency
field Depends)
dpkg-shlibdeps: warning: could not find any packages for
/usr//lib/libtse3.so.0 (libtse3.so.0)
dpkg-shlibdeps: warning: unable to find dependency information for shared
library libtse3 (soname 0, path /usr//lib/libtse3.so.0, dependency field
Depends)

<lots more of this>

[SYSTEM] % cat somefile
shlibs:Depends=libc6 (>= 2.2.4-4), xlibs (>> 4.1.0)

[SYSTEM] % ldd /usr//bin/noteedit (ldd handles this fine)
   libnoteedit.so.1 => /usr//lib/libnoteedit.so.1 (0x40016000)
   libtse3.so.0 => /usr//lib/libtse3.so.0 (0x40109000)
...
   libutil.so.1 => /lib/libutil.so.1 (0x405a8000)
   libdl.so.2 => /lib/libdl.so.2 (0x40934000)
   libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40e47000)
   libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40e55000)
   libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40f30000)
   libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40f39000)
   libresolv.so.2 => /lib/libresolv.so.2 (0x40f4f000)
...


It doesn't "see" libs linked in with // in their name,
whereas it sees so's linked from xlibs and libc6 fine.


It seems dpkg in general cannot handle this either, which I feel is silly
as everything else can. As far as I know having // equate to / is pretty
commonplace in Unix. If there is a good reason to not have dpkg
handle these//files let me know.

e.g.

[SYSTEM] % dpkg -S /usr//bin/noteedit
dpkg: /usr//bin/noteedit not found.

[SYSTEM] % ls -s /usr//bin/noteedit
  12 /usr//bin/noteedit


I imagine the easiest thing is when parsing filepaths is to change
// to /

I know nothing of dpkg source though, and can't speculate how easy this is.

 - bri

severity 122255 minor
thanks

Previously Brian Russo wrote:

How come you have those double slashes in the first place? That looks
somewhat broken.

Wichert.

Yeah, the cause was using --prefix=/usr/ instead of /usr, silly.

Being able to dpkg -S /usr//bin/foo is more important, I think.
That being equivalent to dpkg -S /usr/bin/foo would be stuck on
top of the 'Expected Behaviour' pile, IMHO.

Whether you want to parse somewhat broken /usr//lib/foo lib links
is another story (perhaps this is the linkers fault?)

 - bri