Why kernel packaging is so bad in Debian and Ubuntu

September 20, 2009

I've written before about Ubuntu's substandard kernel update management; what I didn't say then (partly because I didn't fully understand it) is that this is just a manifestation of a general problem with kernel packaging in Ubuntu (and Debian, which it inherits from).

The fundamental problem for packaging kernels on Debian and Ubuntu is that there are two unfortunate design choices in dpkg, the Debian package system: you can only every have one version of a package installed at once, and there is no support for 'multi-arch' packages.

That you can only install a single version of a package at once means that if you want to have multiple kernels installed at once, they must have different package names, not just be different versions of the same package; hence the Debian and Ubuntu necessity of having the kernel version embedded in the package name. This then creates the temptation to do 'minor' kernel updates without changing the package name, and in turn this creates the situation where such a 'minor' change can introduce a bug but leave you with no easy way to reboot to the old kernel.

That packages cannot be multi-arch precludes having kernel packages with the same name but that are for different sub-architectures, so Debian and Ubuntu have to put the sub-architecture into the package name (creating 'linux-image-<blah>-i386' package names and so on). This means that it is impossible to have a generic package name that winds up installing the right kernel-related bit under all circumstances; you cannot have, say, a linux-headers package that installs the correct set of headers for whatever kernel variant you are actually running. Instead you need a different generic package for each kernel sub-architecture variant, and then users have to keep it all straight.

(With multi-arch, a generic linux-headers package would depend on linux-headers-<kver>, there would be various sub-architecture versions of the latter package, and the package system would sort out which sub-architecture was the right one. Without multi-arch (or conditional dependencies), this can't work.)


Comments on this page:

From 89.100.145.29 at 2009-09-20 03:43:28:

Packages can be multiarch, and there's two meta packages (linux-headers-generic, linux-headers-server), that provide the headers for the generic and server kernels.

Written on 20 September 2009.
« Why I am not a fan of hardware acceleration
Exploring the frame object f_builtins member »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sun Sep 20 00:47:19 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.