I may be missing something but I do see a path that may be clean without inventing new package manager features or relying on brittle, text-based version strings. The concern regarding loose version matching and local source rebuilds breaking the ABI is real, but IMHO we don't need to invent a new package manager feature to fix it.
As long as `CONFIG_MODVERSIONS` is enabled, why not simply hash a sorted version of CRCs Module.symvers, (maybe needing to use KBUILD_EXTRA_SYMBOLS for external dependencies? for some distros) Then use `Provides: kernel-abi-token = <hash>` and `Depends: kernel-abi-token = <hash>` and let people use weak depanancies. You could have a monolithic source recipe, but the automated build pipeline programmatically spits out separate .deb, .rpm, or .pkg.tar.zst files for each module. There is a complexity shift to the repository infrastructure but does not require sub-packaging and also solves the local build conflict problem at least in the common case I am thinking about. I guess the recommends may get a bit large and require metapackages by following the simplest pattern: ``` Package: linux-image-generic Recommends: linux-module-pppoe, linux-module-sctp, linux-module-rds, ... ``` So there may be some risk based packaging decisions to make or... To me it seems that `Provides: kernel-abi-token = <hash>` resolves many of the above concerns. On Fri, Sep 18, 2026 at 11:57 AM Eli Schwartz <[email protected]> wrote: > > On 9/18/26 11:30 AM, Kevin Riggle wrote: > > Would it be as conceptually straightforward on the distro side as > > breaking most of these less-common modules out into their own > > packages, e.g. linux-module-pppoe, linux-module-sctp, etc? > > That is exactly what Hanno said to do, so I presume that he thinks it is > as simple as that. > > There are, of course, challenges. Not all distribution package managers > support split subpackages -- the Gentoo package manager does not, albeit > people often compile from source on that distro ;) so it is redundant > for the most part but also impossible to implement for > "gentoo-kernel-bin", or for `--getbinpkg "gentoo-kernel"`. > > It also opens up a slightly worrying concern, that if you don't ship the > whole thing together they can get out of sync. I doubt it would be very > good for ABI if modules can be built against one kernel .config, then > loaded against a very different one because package managers aren't > describing the binding between two packages with anything closer than a > > rundepend=" > ${parent_package}==${exact_release_tag}-${monotonic_integer_buildid} > > " > > Depending on package manager, buildid may be stored as: > > - part of the "Version" field (e.g. debian) and defined purely as a > versioning convention > > - some extra field that is parsed as a version, e.g. Gentoo "${PR}" > (package revision) or Arch Linux "pkgrel", rpm "Release:", etc. > > > Where it exists, it inevitably refers to a text value in a build recipe. > For rpm, you can use %autorelease which parses git log; it doesn't > really solve the problem here. > > So you would have to be very careful about consistently incrementing > that and then it would break anyway if someone decides to rebuild an > existing package from source, which, well, *kernels* and people > rebuilding from source. ;) Hardly uncommon. > > It's quite rare for software to need such tight binding. So adding such > a package manager feature (to bind subpackages to an extra metadata > field outside of version + revision/buildid, probably a UUID or hash) is > potentially a lot of one-off effort. > > ... > > Alternatively, kernels could ship with a default /usr/lib/modprobe.d > file that sets "install ... /bin/false" for modules that are shipped but > "a bad idea unless you really know you need it". The size of the > resulting package cannot be minimized by dropping unneeded large files, > but that's the status quo today. It seems eminently reasonable that this > would solve the security issue, and people could install an override in > /etc/modprobe.d for any modules they don't want to be masked. > > Some distros also have a package manager config file setting > (INSTALL_MASK, NoExtract) to skip individual filenames or filename globs > from being unpacked by any package. It is a bit bulky to use (one record > per module you don't use) and likely not suitable for automatic > deployment with user opt-out as it's quite disruptive if you do end up > needing the module. > > > -- > Eli Schwartz
