--- /dev/null
+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.
<name>Maintainer: Manoj Srivastava </name>
<email>srivasta@debian.org</email>
</author>
+ <author>
+ <name>Maintainer: Julian Gilbey </name>
+ <email>J.D.Gilbey@qmw.ac.uk</email>
+ </author>
<author>
<name>Maintainer: The Debian Policy group </name>
<email>debian-policy@lists.debian.org</email>
<item>
<p>Philip Hands <email>phil@hands.com</email></p>
</item>
+ <item>
+ <p>Julian Gilbey <email>J.D.Gilbey@qmw.ac.uk</email></p>
+ </item>
<item>
<p>Manoj Srivastava <email>srivasta@debian.org</email></p>
</item>
</p>
<p>
- Its arguments are executables
+ Its arguments are executables and libraries
<footnote>
<p>
They may be specified either in the locations in the
</p>
<p>
- If some of the executable(s) shared libraries should only
+ If some of the found shared libraries should only
warrant a <tt>Recommends</tt> or <tt>Suggests</tt>, or if
some warrant a <tt>Pre-Depends</tt>, this can be achieved
by using the <tt>-d<var>dependency-field</var></tt> option
<sect1><heading><em>How</em> does <prgn>dpkg-shlibdeps</prgn>
work?
</heading>
-
<p>
- <prgn>dpkg-shlibdeps</prgn> calls <prgn>ldd</prgn> to
- determine the shared libraries used by the compiled
- binaries passed through its command line.
+ <prgn>dpkg-shlibdeps</prgn> calls <prgn>objdump</prgn> to
+ determine the shared libraries directly
+ <footnote> a binary <tt>foo</tt> directly use a library
+ <tt>libbar</tt> if it is linked with that library. Other
+ libraries that are needed by <tt>libbar</tt> are linked
+ indirectly to <tt>foo</tt>, and the dynamic linker will load
+ the automatically when it loads <tt>libbar</tt>.
+ </footnote> used by the compiled binaries and libraries
+ passed through its command line.
</p>
<p>
kernel-headers Kernel header files (<linux/*.h>, <asm/*.h>)
kernel-image Kernel image (vmlinuz, System.map, modules)
kernel-source Kernel source code
+linux-kernel-log-daemon A daemon to facilitate logging for the Linux kernel
lambdamoo-core A lambdamoo-compatible datebase package
lambdamoo-server Anything running a moo using a lambdamoo-core
libc-dev Anything that provides header and object files
pdf-viewer Anything that can display PDF files
postscript-preview Any preprocessor that creates Postscript output
postscript-viewer Anything that can display Postscript files
+system-log-daemon A daemon that provides a logging facility for
+ other applications
tclsh Anything that provides /usr/bin/tclsh (*)
ups-monitor Anything that is capable of controlling an UPS
wish Anything that provides /usr/bin/wish (*)
Added man-browser
Added ident-server
Alphabeticised lists
+
+Manoj Srivastava
+ 11 July 2000 Added x-terminal-emulator
+ Added x-window-manager
+ Added xserver
+ Added linux-kernel-log-daemon
+ Added system-log-faemon
projects / debian / debian-policy.git / commitdiff