On Thu, Apr 06, 2006 at 05:52:34PM +1000, Steve Kowalik wrote: > On Tue, 4 Apr 2006 17:40:41 +0200, Marc Haber uttered > > Since a package cannot be forced to depend on all indirect > > dependencies, I'd vouch for removing this check. exim4 is also plagued > > by this, and will have a override added. > > > But indirect dependancies are not checked. What we look for is the > libraries that the binaries themselves link to, using objdump. objdump > only lists libraries the binary itself requires through it's NEEDED > section. What is probably happening here is that the SONAME of the > library doesn't match the package name enough that Linda knows that it > is depended upon.
I'm hit by the same bug on wmcpuload 1.0.1-3 (currently available on http://greek0.net/debian/packages/wmcpuload/5/). Here is the data: [EMAIL PROTECTED]:~/work/pkg$ grep Depends DEBIAN/control Depends: libc6 (>= 2.3.6-6), libx11-6, libxext6, libxpm4 [EMAIL PROTECTED]:~/work/pkg$ objdump -p usr/bin/wmcpuload | grep NEEDED NEEDED libX11.so.6 NEEDED libXext.so.6 NEEDED libXpm.so.4 NEEDED libc.so.6 The relevant piece of code is BinaryCheck.links_shlibs() in checks/binary.py. You iterate over all the sonames found in the ELF files, and try to find a dependency for each soname via (line 146): for dep in dependencies: if dep.startswith(libs[lib]): found = 1 The problem is that this falls apart as soon as the soname is different from the library name. This hit you with libpam_misc. In the case of wmcpuload the test fails too (notice capitalisation): 'libxext6'.startswith('libXext') IMHO you have several choices: * Remove the test altogether * Continue to patch it together as you currently do (libz, libpam, libc, ... * Start to use shlibs The shlibs thing certainly sounds nice, but on a closer look it seems nasty too. If you use /var/lib/dpkg/info/*.shlibs the result of linda depends on the libraries currently installed on the system, which probably sucks. If you use your own list you have to keep that up to date which sucks too. Adding all the exceptions to the code could work, but IMHO it would suck if there were too many of them. This could be found out however.. Removing the test might actually be ok too, since it doesn't add much security. dpkg-shlibdeps/dh_shlibdeps exists, so missing deps shouldn't occur too often. What would be really helpful is a warning if you built against a too old version of a library, but the current test doesn't protect against that anyway. HTH, Christian Aichinger
signature.asc
Description: Digital signature
