[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Dependencies of pseudo-essential packages

[Please do not cc libblkid1@packages on follow-ups.]


As you may remember, about 10 years ago [1] the question of whether to
treat all dependencies of essential packages as pre-dependencies came
up.  The result AFAICT was that this is a bad idea, since it doesn’t
allow maintainers of essential packages to distinguish between core
and non-core functionality in the dependencies [2].

Makes sense to me.  There are few enough essential packages that it is
not too much to ask for maintainers to check through the dependencies,
see which are required for the core functionality, and discuss on
debian-devel how to safely add an appropriate pre-dependency or avoid
adding the feature.

Now I am thinking about a related question: should dependencies of
non-essential pseudoessential packages be automatically treated as

What policy says

I think policy says no.  Imagine an essential package E, with a
pre-dependent package P which depends on libc6 (>= 2.10)

	When a package declaring a pre-dependency is about to be
	unpacked the pre-dependency can be satisfied if the
	depended-on package is either fully configured, or even
	if the depended-on package(s) are only unpacked or
	half-configured, provided that they have been configured
	correctly at some point in the past (and not removed or
	partially removed since). (§7.2)

Imagine E has just gained a pre-dependency on P, P and libc6 are
installed with old versions, and we are in the midst of an upgrade.
First, P is unpacked, then the new E.  If we try to use the core
features of P (through E) before the new libc6 is unpacked, then P can
fail because of unresolved symbols.

Similarly, also in §7.2:

	A Depends field takes effect only when a package is to be
	configured. It does not prevent a package being on the
	system in an unconfigured state while its dependencies
	are unsatisfied, and it is possible to replace a package
	whose dependencies are satisfied and which is properly
	installed with a different version whose dependencies are
	not and cannot be satisfied;

If I understood this (and the dpkg source code) correctly, this means
that when unpacking a new version of P, its Depends do not need to be
satisfied.  Imagine P and libc6 are installed with old versions, and
the essential package E pre-depends on P.  Now P is unpacked.  If we
try to use the core features of P through E before the new libc6 is
unpacked, bang.

Existing practice in the archive

$ grep-dctrl -n -FEssential yes -sPackage /var/lib/apt/lists/*sid*Packages |
   sort -u > essential
$ grep-dctrl -n -FEssential yes -sPre-Depends /var/lib/apt/lists/*sid*Packages |
   tr ',' '\n' | sed -e 's/^ //' -e 's/ (.*)//' |
   sort -u > direct-pseudo-essential
$ comm -13 essential direct-pseudo-essential
sysv-rc | file-rc

There are more pseudo-essential packages than these, of course, but
these will do for a start.

 - awk is basically essential.  The packages providing awk use
   Pre-Depends for their dependencies.

 - e2fslibs Depends: libc6 (>= 2.7).  Since lenny has 2.7 and other
   essential packages already pre-depend on it, this looks safe to

 - initscripts (like sysvinit itself) Depends: on various packages.
   The most interesting of these is sysvinit-utils (>= 2.86.ds1-64),
   which it depends on for the fstab-decode program, to free up space
   before unmounting swap on shutdown (not core functionality, I

 - libacl1 Depends on the libraries it is linked to, which have not
   changed since lenny.

 - libblkid1 Depends on the libraries it is linked to.  The
   required version of libuuid1 is not in lenny.

 - libc6 Depends on libc-bin (thus ldconfig) and libgcc1.

 - libcomerr2 Depends on libc6.

 - libncurses5 Depends on libc6.

 - libpam0g Depends on libc6 and debconf.

 - libpam-modules Pre-Depends on all its dependencies, including
   libc6 and libdb4.8.  The pre-dependency on libdb4.8 is necessary
   because it did not exist in lenny.  The ability to log in is pretty

 - libpam-runtime Depends on some packages, but that’s just to support its
   maintainer scripts.

 - libselinux1 Depends on libc6.

 - libsepol1 Depends on libc6.

 - libss2 Depends on libcomerr2 and libc6.

 - libuuid1 Depends on passwd and libc6.  The former is to support its
   maintainer scripts.

 - lzma Depends on libc6, libgcc1, and libstdc++6.  The required
   versions are pseudo-essential lenny.

 - sysv-rc Depends on debconf, sysvinit-utils, and insserv.
   That version of sysvinit-utils is for startpar and sysv-rc can
   cope without it; the other dependencies are for maintainers scripts

 - file-rc has no non-essential dependencies. :)

 - zlib1g depends on libc6.

All of this seems policy-compliant to me, except that libblkid1
should be pre-depending on the required version of libuuid1.

Am I understanding correctly?  If so, would it be worthwhile for me
to write something about this to add to DevRef?

Other thoughts?


[1] http://lists.debian.org/debian-policy/1998/03/msg00131.html
[2] http://lists.debian.org/debian-policy/1998/03/msg00244.html

Reply to: