Hi DKMS and Apt developers--
The upstream author of wireguard (Jason Donenfeld,
https://wireguard.com/, in Cc here) and i were talking about the
potential of building and distributing (within debian) a binary package
for the wireguard linux kernel module. Currently, debian users
typically install the kernel module with dkms, but i'd like to
streamline that, at least for common administrators.
This e-mail explores the problem and asks for help solving it or
pointers to documentation about why we shouldn't solve it. I know i'm
not the first person to try to think this through.
Why not just DKMS?
------------------
dkms is nice because it works universally as long as the right
dependencies (linux headers, compiler) are installed. But it would be
even easier for system administrators if we can ship a binary module
directly, at least for users of our kernels. i'd like to help provide
that ease of use, as sysadmins on debian are used to apt figuring out
the package dependency graph for them and just Doing The Right Thing™.
But kernel headers and a compiler are pretty heavyweight, and the DKMS
process makes package installation significantly slower, especially on
resource-constrained machines -- the very machines that wireguard runs
nice and fast on :)
It seems like we ought to be able to solve this problem within debian,
given that it is all free software. And in the past i remember there
being some kinds of $foo-modules-$abi packages (maybe a long time ago, i
see references to openafs-modules-2.2.18 in
/usr/share/doc/openafs-modules-source/README.modules), but i know
they're not here now, and i don't know exactly why they went away.
openafs stopped shipping them > 10 years ago with this rather terse
explanation "poses too many problems" (i'm cc'ing Russ in case he has
any recollection of why):
https://salsa.debian.org/debian/openafs/commit/085dcac869542f2e0e69b40ccdfac7e8428c8d72
Rejected ways to solve the problem
----------------------------------
Advice like
https://vincent.bernat.ch/en/blog/2018-packaging-driver-debian-dkms is
useful for people with large deployments and/or custom kernels, who can
manage their own CI infrastructure, but those are not the main people
i'm interested in reaching. I'm particularly interested in getting this
working for administrators with less operational bandwidth, so that they
can just depend on the debian package repositories as long as they're
running stock debian kernels.
There's also module-assistant instead of dkms (I'm cc'ing Andreas and
Eduard, the two most active recent authors here), but i think it has the
same drawbacks as dkms -- either more local infrastructure, or
install-time compilation is required.
I'm also assuming here that we don't want arbitrary out-of-tree kernel
modules to block deployment and distribution of the Linux kernel itself,
so explicitly changing the linux source package is probably off the
table. If you think that might be wrong, let me know!
Problems/Goals
--------------
a) ideally, we'd do this for all debian architectures, against all
supported/shipped kernel variants on each arch. This sounds not
only exhausting, but difficult to keep track of -- how would we sync
this when new kernel variants are added (or deprecated kernel
variants are removed)?
b) when the kernel changes ABI, we would need to trigger a rebuild of
the package, presumably pointing to the new ABI. This causes a bit
of a lag in unstable, and the generated packages wouldn't
necessarily even migrate to testing at the same time as the updated
kernel.
c) we'd also like there to be some mechanism to discourage rebooting
the machine to a new version of the kernel that doesn't have the
matching binary module package available yet. for example, if the
system has linux-image-4.19.0-5-amd64 and (say)
linux-module-wireguard-4.19.0-5-amd64 installed, and then the admin
installs linux-image-4.19.0-6-amd64, we want them to know that they
probably shouldn't reboot into 4.19.0-6-amd64 until they *also* have
linux-module-wireguard-4.19.0-6-amd64 installed.
I suspect most debian admins would find it easiest if this was
represented by a dependency in apt, so that the linux-image-$ABI
wouldn't be installed (or wouldn't be *successfully* installed?) if
wireguard-module-$ABI wasn't also installed, but i don't know how
to do that exactly.
Maybe there are other concerns too? please list them if you know of them :)
Ideas for Workarounds
---------------------
I don't know how to solve (a), but i can imagine taking the easy way out
initially and just picking a small number of target architectures and
focusing on the most popular kernel variant on those architectures for
now. Simplest would be to just start with amd64, with the -amd64
variant. i know that leaving it that way would make a lot of people
sad, but i think starting simple is a good way to go; if we show that it
works, we can generalize from there.
I am also not sure how to automatically solve (b) in a clever way, but
in the meantime, we can just keep track of what linux-headers-$ABI is
available on the given targeted platforms, and update the source package
when that happens. This introduces even more of a delay between when
the new ABI is available for the kernel, and when it's available for the
module (including a round-trip through NEW), but perhaps that delay
won't be too painful either, though the longer the delay, the more
people can get burned by a failure to solve (c).
I don't know that i even have a workaround for (c), though. i could
make the kernel package's postinst fail by dropping something in
/etc/kernel/postinst.d/ that rejects the installation if
linux-module-wireguard-$ABI isn't also installed, but the only thing we
can really do at that point is to cause the installation to fail and
print out an error message/warning. That seems pretty ugly to me, and
it'd be much nicer to somehow see an explicit dependency in apt itself
-- but i don't want that dependency to exist on systems that don't want
wireguard installed at all.
Maybe there's some way that a package can inject an edge in apt's
dependency graph deliberately? or is there some other approach that apt
developers would think makes more sense?
--dkg
Attachment:
signature.asc
Description: PGP signature