Changes in dpkg Pre-Depends
Hi!
As I'd like to change some Pre-Depends in dpkg, I'm bringing this up
here for discussion, as per policy §3.5 and given dpkg “Essential: yes”
nature.
First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,
the latter is a bit bigger in size (lzma 172 KiB; xz-utils 504 KiB,
160 KiB in share/doc/ and liblzma2 304 KiB, 124 KiB in share/doc/) but
it supports both “.lzma” and “.xz” formats, in the imminent future
dpkg-deb will get switched to directly use liblzma-dev so that one will
disappear, Jonathan Nieder has already sent some patches for that, they
need some changes first, so probably after next release (after 1.15.6).
Second, I'd like to switch from statically to dynamically linking
against zlib and libbz2, eventually liblzma too (affecting dpkg-deb)
and libselinux (affecting dpkg itself only on Linux). Here's the
arguments I know of against and in favour, with rebuttals:
Robustness (against)
~~~~~~~~~~
It's one of the few native packages (if not the only one) that is still
statically linking. One of the reasons for that has been for robustness
for several scenarios of brokenness. Let's see:
* If dynamic linking does not work in general for whatever reason,
then libc would be affected, and mostly nothing would work anyway.
* If one of the specific shared libraries breaks due to the file
being disappeared/broken/corrupted then executing dpkg or dpkg-deb
would fail, but so would lots of other things, and installing a
package might be the lesser of your problems.
* If one of the specific shared libraries breaks due to broken ABI,
or an implementation bug, then it might only affect the code using
those libraries, which might not trigger at all (say one does not
have SE Linux enabled, or does not install a bzip2 compressed
package).
Statically linking might allow an easier recovery of the system, but
with enough skills most broken systems can be recovered, and the less
skilled users will not be able to w/o assistance anyway, and most
probably their GUI environments will not work either. This is though
the strongest argument about keeping status quo, and personally is the
one which has made me hesitate for a long time in proposing such change,
but if we cannot safely use shared libraries at this point in time,
then maybe we are doing something wrong.
There's also the argument that dpkg internally uses other commands to
perform operations (namely tar, find, rm and sh) and if any of those
breaks, dpkg will not be able to operate at all in some circumstances.
Increase in dpkg dependencies (against)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Statically linking might make backporting or just installing a newer
dpkg.deb in an previous Debian release easier. Except for liblzma which
is not yet in a stable release zlib, libbz2 and libselinux have long
been there, and it would be a matter of not using symbols too new to
avoid getting a versioned dependency on a package not in stable.
Increase in the pseudo-essential set (neutral)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
zlib and libselinux are already part of the pseudo-essential set.
Dynamically linking against libbz2 and liblzma would pull those as new
pseudo-essential dependencies, but then the size just gets shifted from
dpkg to the actual shared library packages, and in addition it allows
others to make use of them, and not only dpkg (by way of having them
embedded while statically linked).
zlib ← util-linux
libselinux ← coreutils, sed, util-linux, libpam-modules, sysvinit
Size reduction (favour)
~~~~~~~~~~~~~~
It will make dpkg.deb slightly smaller, although not much noticeable
given the huge percentage taken presently by l10n files, but it is
somehow significant for a stripped binary (with locales and docs
removed, but not man pages). This will make dpkg.deb get closer to be
usable in really space constrained environments, the next reduction
will be when switching to use libdpkg.so. After some more culling it
might even be a possible candidate to replace stuff like udpkg, ipkg,
opkg and friends. For the actual size changes, taking numbers from
current master:
w/ static linking:
-rwxr-xr-x root/root 408488 2010-02-19 20:04 ./usr/bin/dpkg
-rwxr-xr-x root/root 257608 2010-02-19 20:04 ./usr/bin/dpkg-deb
-rw-r--r-- 1 guillem guillem 533642 Feb 19 20:30 dpkg-strip-static.deb
w/ dynamic linking:
-rwxr-xr-x root/root 219488 2010-02-19 20:13 ./usr/bin/dpkg
-rwxr-xr-x root/root 126824 2010-02-19 20:13 ./usr/bin/dpkg-deb
-rw-r--r-- 1 guillem guillem 380694 Feb 19 20:30 dpkg-strip-dynamic.deb
Security (favour)
~~~~~~~~
Avoids the usual security problems when dealing with statically linked
code.
Avoiding static PIC libraries (favour)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When dpkg switches to use a shared libdpkg, those libraries will need
to be linked dynamically anyway, or we'd have to produce PIC enabled
static libraries (ugh), which I'd strongly be against.
So if there's no strong reason not to, I'd like to do these changes for
next dpkg 1.15.6 release. Note though that they are not interdependent,
and if we decided so, one could be done while not the other.
thanks,
guillem
Reply to: