Russ Allbery wrote:
It's conceptually similar, but since kernels are tied directly to a
Debian architecture, it's easier to handle the kernel case using our
existing infrastructure. There just isn't a binary package for that
architecture if it doesn't work with that kernel, and most of the
problematic cases, such as switching between init systems, don't apply
in an analogous way.
There's a related case that seems exactly similar, though: some packages
need to depend on specific kernel features or versions, but that's not
currently representable in the packaging system. You can't currently
depend on a kernel with CONFIG_FOO available (or with the module
installed), or a kernel with the foo syscall, or kernel version
3.10. That restriction against depending on a kernel applies for a
variety of reasons: to support locally compiled and installed kernels,
to allow for multiple installed kernels chosen at boot time, and to cope
with having a kernel installed without having booted into it (perhaps
because you haven't rebooted yet).
While we don't need to support locally compiled and installed init
systems (anyone doing that can use equivs or package it properly), we
may potentially want to support multiple installed inits in parallel, we
may want to support selecting them at boot time, and we *definitely*
have to handle the case where you've installed a new init but not yet
rebooted into it.
It'd be nice to have a solution to both of those problems. Perhaps we
could (start the multi-release process to) augment dpkg to support
special dependencies such as kernels and init systems, for instance.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140203220257.GA14066@jtriplet-mobl1
