Description

While Kernel Module Packages are the 2nd-best thing invented since sliced bread, their hanlding in practice poses some challenges to users.

Goals

Improve the KMP concept and the related code (/usr/lib/rpm/kernel-module-subpackage, weak-modules2) for a better end user experience. In particular, such that seamless installation and update of KMPs is possible, with and without KABI differences between kernels.

Detailed description

The way kernel module packages currently work:

• KMPs install their modules in the updates subdirectory of the module directory of the kernel they were build for
• In posttrans, the weak-updates2 tool creates symlinks from the weak-updates2 subdirectories to modules installed in updates of KABI-compatible kernels.
• The version of the KMP is constructed by concatenating the actual module version with the version of the kernel it was built for.
• By default, Provides: multiversion(kernel) is set in KMP packages.

KMP versions can change either because a new version of the KMP is published, or because the same KMP is compiled against a different SUSE kernel, or both. Because of multiversion(kernel), multiple KMPs compiled against different kernels can coexist on a single system. But this has some strange side effects.

1. KMPs compiled against update kernels aren't necessarily compatible with older kernels from the same service pack, because KABI compatiblity is "forward only".
2. Different versions of the KMP compiled against the same kernel cannot coexist because of file conflicts (they install into the same path).
3. If a new KMP version is provided by compiling it against an update kernel N, and an older KMP is installed for another older kernel O, weak-updates symlinks to N will be created for all compatible kernels except O, because for O, the older module installed in updates prevents it. This holds even if the module compiled for N was KABI-compatible with O.
4. KMPs can generally not be updated but only installed, in which case the user has to go through conflict resolution dialgos presented by zypper.

OTOH, if Provides: multiversion(kernel) is not set, only one KMP of a given name can be installed at a given point in time. KMP updates are possible, but if the KMP is compiled against a newer kernel, it may not be compatible with older kernels any more (and KMPs matching older kernels have to be uninstalled). The biggest problem in this case occurs if for whatever reason the KABI cannot be kept stable by SUSE through a Service Pack. This can happen in the case of major security issues such as Meltdown/Spectre, for example. In this case, it's necessary to update the kernel to fix the vulnerability, and at the same time update the KMP so that it's compatible with the KABI of the updated kernel. If the KMP is necessary for booting and there is some (possibly unrelated) bug that prevents the new kernel from booting, the system may become unbootable because the KMP is now missing for the previous kernel. A snapshot rollback would fix that situation, but it's not always available.

Approach

• Enable installation directories for modules outside of the kernel module hierarchy, unique for each KMP
• Experiment with a different KMP package naming / versioning convention that makes the kernel version part of the package name rather than the package version. The name would express "KMP X for kernel Y", similar to what we do e.g. with python modules like python313-six (module six for python 3.13).