Sam Hartman <hartm...@debian.org> writes: > B) They might already have headers installed. Imagine someone who > installs headers at the same time they install the kernel. Unless they > managed to upgrade the same version of their kernel without also > upgrading their headers, they will still have headers. They can still > build modules against that kernel, either because they installed a new > dkms package, or because one of their dkms packages upgraded.
I am also really confused by this discussion and don't entirely understand the motivation for the proposed change to kernel headers, but isn't the situation Sam describes above the normal way Linux kernel headers work and have worked for years? Kernels come with headers matching the same version, if you want headers for external modules you install both packages at the same time via one mechanism or another, and you only remove the kernel and headers when you're pretty sure you will never use that kernel again. When I was using external modules heavily, I routinely kept three or four old kernels and their corresponding headers installed at the same time so that I could easily downgrade if I ran into regressions without having to track down old packages that may have been removed from the archive. This feels like a normal and somewhat obvious Debian systems administration thing to do to me. I realize in the new signing regime every new kernel would have a separate headers package (as opposed to today where the kernel and headers are updated in place with the same package name if there is no ABI change), but to me this doesn't feel like a significant difference for users. I haven't been paying close attention, so maybe I'm wrong, but I feel like most kernel package updates have been ABI updates anyway, particularly in stable. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
