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

[Samuel Thibault <samuel.thibault@ens-lyon.org>]

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:

--- /usr/bin/dpkg-shlibdeps	2004-11-11 21:15:52.000000000 +0100
+++ /mnt/hurd/bin/dpkg-shlibdeps	2004-12-15 00:17:05.000000000 +0100
@@ -193,6 +193,29 @@
         close STDERR; # we don't need to see dpkg's errors
 	open STDERR, "> /dev/null";
         $ENV{LC_ALL} = "C";
+        exec("dpkg","--search","--",map {"/usr$_"} @libfiles); syserr("cannot exec dpkg");
+    }
+    while (<P>) {
+       chomp;
+       if (m/^local diversion |^diversion by/) {
+           &warn("diversions involved - output may be incorrect");
+           print(STDERR " $_\n") || syserr("write diversion info to stderr");
+       } elsif (m=^(\S+(, \S+)*): /usr(\S+)$=) {
+           push @{$pathpackages{$+}}, split(/, /, $1);
+       } else {
+           &warn("unknown output from dpkg --search: \`$_'");
+       }
+    }
+    close(P); 
+}
+
+if ($#libfiles >= 0) {
+    grep(s/\[\?\*/\\$&/g, @libname);
+    defined($c= open(P,"-|")) || syserr("cannot fork for dpkg --search");
+    if (!$c) {
+        close STDERR; # we don't need to see dpkg's errors
+	open STDERR, "> /dev/null";
+        $ENV{LC_ALL} = "C";
         exec("dpkg","--search","--",map {"$_"} @libfiles); syserr("cannot exec dpkg");
     }
     while (<P>) {

Could you consider applying something like this, or at least provide it
in the package so that hurd people may apply it to avoid the trouble
when building packages ?

Well, maybe the dpkg --search itself may be patched for hurdish /usr
behavior ?

Regards,
Samuel Thibault

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)

Versions of packages dpkg-dev depends on:
ii  binutils                      2.15-5     The GNU assembler, linker and bina
ii  cpio                          2.5-1.1    GNU cpio -- a program to manage ar
ii  make                          3.80-9     The GNU version of the "make" util
ii  patch                         2.5.9-2    Apply a diff file to an original
ii  perl [perl5]                  5.8.4-3    Larry Wall's Practical Extraction 
ii  perl-modules                  5.8.4-3    Core Perl modules

-- no debconf information