+In woody dpkg will use a different method to determine on which
+libraries a package should depend. Until now dpkg-shlibdeps has
+used the output of ldd to determine which libraries are needed.
+This will be changed to using objdump. This however changes
+will need a couple of changes in the way that packages are build.
+
+Let me first explain the differences between ldd and objdump.
+A binary itself is linked against 0 or more dynamic libraries, depending
+on how it is linked. Some of those libraries may need other libraries
+to do their work, so the linker will need to load those as well when
+the binary is executed. For example, to run xcdrgtk needs the following
+libraries according to ldd:
+
+ libgtk-1.2.so.0 =3D> /usr/lib/libgtk-1.2.so.0 (0x40019000)
+ libgdk-1.2.so.0 =3D> /usr/lib/libgdk-1.2.so.0 (0x4013d000)
+ libImlib.so.1 =3D> /usr/lib/libImlib.so.1 (0x40170000)
+ libgdk_imlib.so.1 =3D> /usr/lib/libgdk_imlib.so.1 (0x401ab000)
+ libc.so.6 =3D> /lib/libc.so.6 (0x401d9000)
+ libgmodule-1.2.so.0 =3D> /usr/lib/libgmodule-1.2.so.0 (0x402b5000)
+ libglib-1.2.so.0 =3D> /usr/lib/libglib-1.2.so.0 (0x402b8000)
+ libdl.so.2 =3D> /lib/libdl.so.2 (0x402da000)
+ libXi.so.6 =3D> /usr/X11R6/lib/libXi.so.6 (0x402de000)
+ libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x402e6000)
+ libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x402f3000)
+ libm.so.6 =3D> /lib/libm.so.6 (0x40392000)
+ libjpeg.so.62 =3D> /usr/lib/libjpeg.so.62 (0x403af000)
+ libtiff.so.3 =3D> /usr/lib/libtiff.so.3 (0x403cf000)
+ libungif.so.3 =3D> /usr/lib/libungif.so.3 (0x40411000)
+ libpng.so.2 =3D> /usr/lib/libpng.so.2 (0x4041a000)
+ libz.so.1 =3D> /usr/lib/libz.so.1 (0x40442000)
+ /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)
+
+Now if we leek a bit closed we see that xcdrgtk actually only links to
+a couple of those libraries directly. The actual depencies are a tree
+which looks something like this: (anyone interested in writing a tool
+to make such a graph?)
+
+ xcdrgtk
+ +- libc
+ +- gtk
+ +- gdk
+ | +- libXi
+ | +- libXext
+ | \- libX11
+ +- Imlib
+ | +- libjpeg
+ | +- libtiff
+ | | +- libjpeg
+ | | +- libm
+ | | \- libz
+ | +- libungif
+ | | \- libX11
+ | +- libpng
+ | | +- libz
+ | | \- libm
+ | +- libz
+ | \- libm
+ \- gdk_imlib
+ +- libgmodule-1.2
+ | \- libdl
+ +- libglib-1.2
+ \- libdl
+ \- ld-linux
+
+(I haven't listed libc in here, but all libraries are also linked to
+libc).
+
+What ldd does is give us a complete list of every library that is needed
+to run the binary (in other words, if flattens this tree). objdump
+however can tell us exactly what library something is linked with. For
+the same xcdrgtk binary it will tell us:
+
+ NEEDED libgtk-1.2.so.0
+ NEEDED libgdk-1.2.so.0
+ NEEDED libImlib.so.1
+ NEEDED libgdk_imlib.so.1
+ NEEDED libc.so.6
+
+All the other libraries are automatically pulled in by the dynamic
+loader.
+
+And now for the connection to package management: a package only
+needs to depend on the libraries it is directly linked to, since the
+dependencies for those libraries should automatically pull in the
+other libraries.
+
+This change does mean a change in the way packages are build though:
+currently dpkg-shlibdeps is only run on binaries. But since we will
+now depend on the libraries to depend on the libraries they need
+the packages containing those libraries will need to run dpkg-shlibdeps
+on the libraries. That may sound a bit strange, so here is an example:
+
+Generally a package does this in debian/rules:
+
+ dpkg-shlibdeps debian/tmp/usr/bin/*
+
+This will need to be changes to:
+
+ dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/lib/lib*.so.*
+
+For lib* packages which don't generally contain libraries and didn't
+run dpkg-shlibdeps a dpkg-shlibdeps call will need to be added as well.
+
+This gives us a lot more flexibility in the way libraries are packaged.
+
+A good example where this would help us is the current mess with
+multiple version of the mesa library. With the ldd-based system
+every package that uses mesa need to add a dependency on
+svgalib|svgalib-dummy in order to handle the glide mesa variant.
+With an objdump-based system this isn't necessary anymore and would
+have saved everyone a lot of work.
+
+Another example: we could update libimlib with a new version that supports
+a new graphics format called dgf. If we use the old ldd method every
+package that uses libimlib would need to be recompiled so it would also
+depend on libdgf or it wouldn't run due to missing symbols. However with
+the new system packages using libimlib can depend on libimlib itself
+having the dependency on libgdh and wouldn't need to be updated.