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
Attachment:
pgprbetS1aXWa.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
