Package: dpkg-dev Version: 1.14.16.6 Severity: important File: /usr/bin/dpkg-shlibdeps
When a binary links against a library without using its symbols, and the library is in a package providing .symbols file, dpkg-shlibdeps does put a reference to the package in shlibs, but without a version number. e.g. $ dpkg-shlibdeps -v debian/libnss3-1d/usr/bin/test Scanning debian/libnss3-1d/usr/bin/test (for Depends field) Library libxml2.so.2 found in /usr/lib/libxml2.so.2 Library libc.so.6 found in /lib/libc.so.6 Looking up shlibs dependency of libc.so.6 provided by 'libc6' Found libc6 (>= 2.7-1) in /var/lib/dpkg/info/libc6.shlibs Using symbols file /var/lib/dpkg/info/libxml2.symbols for libxml2.so.2 dpkg-shlibdeps: warning: debian/libnss3-1d/usr/bin/test shouldn't be linked with libxml2.so.2 (it uses none of its symbols). $ cat debian/substvars shlibs:Depends=libxml2 , libc6 (>= 2.7-1) This is what happens without symbols file: $ dpkg-shlibdeps -v debian/libnss3-1d/usr/bin/test Scanning debian/libnss3-1d/usr/bin/test (for Depends field) Library libxslt.so.1 found in /usr/lib/libxslt.so.1 Library libc.so.6 found in /lib/libc.so.6 Looking up shlibs dependency of libc.so.6 provided by 'libc6' Found libc6 (>= 2.7-1) in /var/lib/dpkg/info/libc6.shlibs Looking up shlibs dependency of libxslt.so.1 provided by 'libxslt1.1' Found libxslt1.1 (>= 1.1.18) in /var/lib/dpkg/info/libxslt1.1.shlibs dpkg-shlibdeps: warning: debian/libnss3-1d/usr/bin/test shouldn't be linked with libxslt.so.1 (it uses none of its symbols). $ cat debian/substvars shlibs:Depends=libc6 (>= 2.7-1), libxslt1.1 (>= 1.1.18) While this is not really a problem in such a simple case, it can become problematic when library packages contain several different libraries, one of which was not in previous versions of the package. This is what happens in #474007: /usr/lib/purple-2/ssl-nss.so is linked against libnssutil3 without using any of its symbols, but libnssutil3 doesn't exist before version 3.7.0~beta2-1 of the libnss3-1d package. So dpkg-shlibdeps calculates the version dependency without taking into account libnssutil3 and ends up writing a dependency on older versions, which don't contain libnssutil3. Surely, the nss.pc file could be enhanced to do the right thing, but that won't prevent people linking against libnssutil3 anyways. And strangely, in this case, -Wl,--as-needed *is* being used when linking /usr/lib/purple-2/ssl-nss.so, but sadly, it still keeps the dependency on libnssutil3 while not using its symbols. Anyways, I think when using no symbol, the minimum version of all symbols from the library should be used instead of not version. Or maybe the symbols file should be ignored and the standard shlibs used. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils 2.18.1~cvs20080103-3 The GNU assembler, linker and bina ii bzip2 1.0.5-0.1 high-quality block-sorting file co ii cpio 2.9-12 GNU cpio -- a program to manage ar ii dpkg 1.14.16.6 package maintenance system for Deb ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii lzma 4.43-12 Compression method of 7z format in ii make 3.81-3.1 The GNU version of the "make" util ii patch 2.5.9-4 Apply a diff file to an original ii perl [perl5] 5.8.8-12 Larry Wall's Practical Extraction ii perl-modules 5.8.8-12 Core Perl modules Versions of packages dpkg-dev recommends: ii build-essential 11.3 informational list of build-essent ii gcc [c-compiler] 4:4.2.3-6 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-21 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.3-3 The GNU C compiler -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
