Differences between revisions 1 and 2
Revision 1 as of 2008-06-03 14:07:39
Size: 3797
Editor: pd956a57b
Comment: initial braindump
Revision 2 as of 2008-06-03 14:08:53
Size: 3787
Editor: pd956a57b
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
 * '''Created''': [[Date(2008-06-02)]]  * '''Created''': 2008-06-02


We propose a generalized replacement of linux-meta by improving the package manager and using dependency fields. This makes the upgrade to a new kernel ABI automatically apply to installed third-party drivers as well, and ensures that apt itself ensures consistency of the packages. This provides a way to provide third-party driver packages, eases kernel maintenance, and robustifies the upgrade for people who end up without linux-meta.


Currently, linux-meta provides a rather manual way to upgrade kernel driver packages (such as l-u-m) to a new kernel ABI. However, this is problematic in several ways:

  • It needs to be maintained manually and even with it, people often install de-sync linux and driver packages.
  • It forces/encourages us to throw all third-party drivers into a single monolithic package which is hard to maintain (e. g. l-r-m).
  • It does not apply to anything that is not covered by l-meta itself (linux-{ubuntu,restricted,backports}-modules), such as virtualbox-ose-modules, a lot of other already packaged drivers, and most importantly, packages from third-party driver repositories.

Use Cases

  • Jon uses VirtualBox on Intrepid. After Intrepid gets a new kernel ABI 2.6.26-07, update-manager automatically installs the matching virtualbox-ose-modules-2.6.26-07-generic package, too.

  • James buys a new Dell server which needs a backported SCSI driver which is not yet available in the Hardy kernel. Dell maintains a repository with this driver for Hardy, and updates it when Hardy gets a new kernel ABI. James just runs a normal dist-upgrade, which installs a new kernel ABI, but the Dell update is not yet available. His machine continues to boot with the old kernel. On the next day, the upgraded Dell driver is available, and James' daily upgrade automatically pulls in the SCSI driver for the new kernel ABI. James reboots the machine, which starts the new kernel.


This problem has two major parts:

  1. Automatically install new packages which provide a driver (or the kernel itself) for a new kernel ABI, if the package was installed for the older ABI.
    • (TODO)
  2. Decide when enough drivers have been installed for the new ABI to switch the boot default to the new kernel.
    • Driver packages which are essential for booting declare a package

      field X-Boot-Essential: Yes.

    • A new script /etc/kernel/postinst.d/zz_default_kernel looks at the currently installed packages and flips the boot default to the new kernel once all X-Boot-Essential: Yes packages are available for the new ABI which were available for the currently running ABI.


New package installation

Default kernel selection

  • Move the kernel symlink handling in linux-image-*.postinst into separate script /etc/kernel/postinst.d/zz_default_kernel. This should be shipped in an already existing "kernel infrastructure" package which can be maintained more easily than updating the kernel itself, or possibly a new package linux-common.

  • Create a new debhelper script dh_linux which automatically generates the code for running /etc/kernel/postinst.d/, using dpkg-triggers for efficiency. In 8.04 this is hardcoded in linux-image-*.postinst.

  • The linux-image-* and all kernel driver packages use dh_linux in their debian/rules. This should be done by the autopackaging in dkms as well.


DesktopTeam/Specs/KernelAbiPackageHandling (last edited 2008-08-06 17:01:31 by localhost)