[Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference

[Thorsten Leemhuis]

Axel Thimm schrieb:
> On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:

> o The 'only-last-kernel-supported' simply becomes
>   'only-last-kabi-supported'. For Fedora it's the same anyway.
>   So you still have issues with
>   - no (security) updates for old kernels (or kabis)

I was one of those that wanted to build stuff for older kernels in the
past. But a lot of people disliked that idea (I can look it up in the
archives if someone is interested who that was; most were from RH iirc)
and only wanted to support the latest shipped kernel.

If we really want to support older kernels then we need "uname -r" (or
kabi, or another identifier) in the %{NAME} *or* a plugin that handles
the stuff manually. I think I prefer the "uname -r/kabi" approach in
that case.

The question is: do we want to build new kernel modules for old kernels
that might have known security problems? Old kernels also get deleted
from the servers normally soon and thus aren't all available for the
buildsys anymore (only the current one and the one before that are on
the servers in the update repo). Building modules for all the kernels we
ever shipped would take a lot of build time and space on the servers. A
middle way -- build for all kernels still available wold be an
compromise if we want to build for more that kernel-current.

Axel, sorry, I'm not sure if I understand that "security" reference
above. I understood this currently like this: problem in module -> push
out a updated module and the latest kernel gets a fixed module, olders
remain unfixed. But hey, older kernels often (not always) had security
problems in any case -- that's why there was a new one. Or did I get
something wrong here?

>   - old kernels/kabis can get their module nuked or effectively
>     disabled.

Nope.

> o Currently there is a file conflicst guard of not having different
>   modules for the same kernel coinstalled. The disambiguation in the
>   file path lifts this safety pin and suddenly we can end up with
>   several different module versions for the same kernel!!!

Nope, /sbin/weak-modules {cs}hould handle this.

CU
thl