as announced in
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
- 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.
Premier livre français sur Debian GNU/Linux :
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com