RFC: kernel abi handling/package series
Dear friends,
I would like to ask for opinions on the problem of upgrading sets of
packages which have multiple 'series' in the archive. The primary use
case here is handling kernel upgrades and the kernel abi, but it
equally applies to e. g. postgresql-8.1 vs. postgresql-8.3 and version
specific extension packages.
The kernel provides a ABI that the modules that are not part of the
core kernel package need to be build against. In Debian, the prime
example is linux-modules-extra-2.6 (roughly resembling Ubuntu's
linux-ubuntu-modules), but there are lots of other kernel driver
packages in both distros and in external repositories.
On a upgrade of the kernel with a ABI break, all the module packages
need to be upgraded as well, otherwise the user looses functionatlity
or (in the worst case) is no longer able to boot his system or to use
X. So ideally when the user upgrade from say 2.6.25-1-686 to
linux-image-2.6.26-2-686 all module packages (both from debian and
from potential external repositories) get upgraded
automatically. Furthermore, if some are not yet available but become
available later (because have not be build yet) they would be added
automatically.
We currently lack a good way to express this relation in dependency
information. The current way seems to be to use meta package like
"linux-image-686" and then depend on the current exact version and
abiversion. E. g.:
(Debian:)
Package: virtualbox-ose-modules-2.6.25-2-amd64
Depends: linux-modules-2.6.25-2-amd64
(Ubuntu:)
Package: virtualbox-ose-modules-2.6-686
Depends: virtualbox-ose-modules-2.6.25-2-686
Other packages use similar approaches, but do not have a working
solution for auto-upgrading to a newer series. E. g.:
Package: postgresql-8.3-postgis
Depends: postgresql-8.3
If you are running Etch and have postgresql-8.1 and
postgresql-8.1-postgis installed, you won't automatically get
-8.3-postgis if you upgrade to postgresql-8.3.
While the meta-package approach works we would like to discuss if we
can find a approch that is more elegant to handle this.
This topic was discussed on a recent developer summit, and the current
proposal has been written down as a specification [1]. It proposes to
introduce a new relation field "Package-Series:" which groups related
packages together and thus hints apt to do the right thing on upgrades
without having to manually maintain metapackages, or forcing users to
install a huge big driver package (such as linux-modules-...) although
they only need one particular driver. A package-series behaves a bit
like a task but it would enforce that all packages in a series get
installed if there is a installed package already. A "flat" structure
for the series is not enough, because this way a series like:
Pkg-Series: linux-abi-2.6.24-2-686 would pull in all drivers
available. Similar if we would use it on the driver package
Pkg-Series: ose-modules would pull in all available abi version for
the driver (2.6.22-2-686,2.6.22-2-386,..) So a combination of the two
would be required, the ose driver for 2.6.24-2-686 would declaring to
be part of the "Pkg-Series: ose-modules, linux-abi-2.6.24-2-686"
another one for "Pkg-Series: ose-modules,linux-abi-2.6.22-1-386"
Apt would then look for the package series installed (a package series
is considered installed if one package that declares this series is
installed). Then it checks each package with a Pkg-Series header for
the series that it wants to be part in. If all the series that it
wants to be part in are installed on the system, then this package is
marked for install.
Because the resolver in aptitude is different it would need help from
aptitude as well (and maybe libept too).
Given the complexity that the outlined solution has, we are
interessted in alternative ideas too. One possible alternative idea
was to add plugin support to libapt so that external plugin libraries
could hook into certain bits of apt (e.g. the MarkInstall() call in
pkgDepCache) to provide special resolving functionality. Then we could
add new headers like "Kernel-Driver: foo", "Kernel-ABI: 2.6.25-2-686"
and write a custom kernel-abi plugin for this. Of course c++ and
plugin is a challange in itself too :)
This of couse has the same problem that aptitude (and maybe libept) need to
work with it.
What do you think about all of this?
Thank you in advance,
Michael Vogt and Martin Pitt
[1] https://wiki.ubuntu.com/DesktopTeam/Specs/KernelAbiPackageHandling
Reply to: