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 built/delivered.
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 distinct kernels.
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 https://pagure.io/atomic-wg/issue/493