[Please do not cc libblk...@packages on follow-ups.]
Hi,
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
pre-dependencies?
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
awk
e2fslibs
initscripts
libacl1
libblkid1
libc6
libcomerr2
libncurses5
libpam0g
libpam-modules
libpam-runtime
libselinux1
libsepol1
libss2
libuuid1
lzma
sysv-rc | file-rc
zlib1g
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
me.
- 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
suspect).
- 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
crucial.
- 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
AFAICT.
- 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?
Jonathan
[1] http://lists.debian.org/debian-policy/1998/03/msg00131.html
[2] http://lists.debian.org/debian-policy/1998/03/msg00244.html
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100308204054.ga11...@progeny.tock
