Hello, as announced in http://lists.debian.org/debian-devel-announce/2007/09/msg00004.html the new dpkg-shlibdeps is stricter in what it accepts and will fail when it can't find dependency information for a library that is used by an executable or a public library (a public library is defined as a library which has a SONAME, see the output of "objdump -p").
Failures look like this: dpkg-shlibdeps: failure: No dependency information found for libkdeinit4_kfmclient.so (used by debian/konqueror/usr/bin/kfmclient). It might also look like this: dpkg-shlibdeps: failure: couldn't find library libhpip.so.0 (note: only packages with 'shlibs' files are looked into). I believe this change is good because it makes sure we don't upload packages lacking some important dependency information (see the bug #10807 for a simple example...). But it sure breaks quite a few packages who have "private" libraries with a SONAME. I'm willing to add meaningful exceptions to the rule and I just implemented two of them (not yet committed, so it's not in 1.14.10 recently uploaded): - when the library is in the same package than the binary analyzed - when the library is not versionned and can't have a shlibs file I think those ought to be enough to avoid many build-failures. In all other cases, I believe the right way to fix the failures is to add "shlibs" informations even if they are only used between multiple binary packages of the same source package. It means that dh_makeshlibs needs to be called before dh_shlibdeps of course. If you know of other good exceptions, please tell me. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
