walters added a new comment to an issue you are following:
The core thing here is that since there's no kABI, you are not guaranteed that a
module will work as the host evolves. This is true of non-Atomic Fedora systems today,
and has been true basically forever - nothing new here. What changes is how the host is
Mechanically there's two parts to this. First, there's the question of where the
module gets built. That in turn affects how it's deployed (the second issue).
DKMS builds it on the client. There are also "akmod" variants that have the
modules pre-built for multiple kernels.
Particularly "at scale", I think it makes the most sense to pre-build kernel
modules rather than doing it per-host. If you set up a COPR or whatever, you can query
what kernels "will be" available in the future by looking at Koji builds. If
your built kernel module package then has a `Requires` on the exact kernel version it was
built for, then rpm-ostree client side layering should automatically select the right one
as the primary releases pick up updated kernels.
That's going to work fairly well today because FAH/Silverblue etc. do not carry
Now everything I just said is fundamentally distinct from making a DKMS-style system work
with rpm-ostree which it seems is what you were looking at. For that...let's perhaps
talk in https://github.com/projectatomic/rpm-ostree/issues/1091
To reply, visit the link below or just reply to this email