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

[Axel Thimm]

On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote:
> 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)
> 
> 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?

Do we want to keep those kernels in the repo? Whatever the policy for
kernels it mirrors to the kernel module support. If a kernel is not
worth installing, remove it from the repo and the associated kmdls.

> Building modules for all the kernels we ever shipped 

No, that's not the idea. Only what is considered a sane transition
time from kernel to kernel.

> 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?

In Fedora??? 30% of kernel updates are not security related, and often
some kernels are brown bag releases, so many people back up to the
previous kernel. Supporting the last kernel is important.

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

Yep.

> > 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.

So adding evr semantics to module-init-tools? BTW where is the epoch
in your file path suggestion? ...
Gotcha! :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060816/0cd6f977/attachment.sig>