[fab] Kernel Module packages in Core and Extras

[Thorsten Leemhuis]

Christian Iseli schrieb:
> On Sat, 19 Aug 2006 10:10:10 -0500, Rex Dieter wrote:
>> My $0.02... kernel modules are here to stay, and we simply need to find
>> the best way to deal with it.  No need to waste time fretting otherwise.
> 
> Since we're all dealing out small change... :-)
> 
> We have tons of perl and python modules, and nobody's fretting much
> over it, although they do extend the functionality of the base language
> in one way or another.
> 
> Probably the reason nobody's fretting much is because when something
> goes wrong, users file bug reports with the module owner and not with
> the perl (or python) maintainer...

That only one of the reasons IMHO. The bigger problem from the Extras
standpoint is this:

Let's say the current kernel is kernel-2.6.16-1.2133_FC5. kmod-foo and
kmod-bar are in the repo for that kernel. kernel-2.6.17-1.2139_FC5 get
pushed out. kmod-foo build fine for the new kernel and gets pushed to
the repo. But some API changes in the 2.6.17 kernel break kmod-bar. The
upstream maintainer of bar is lazy and says "it'll take some time until
it'll get fixed." So people depending on kmod-bar will stick to the old
kernel. Now lets further assume kernel-2.6.17-1.2145_FC5 get pushed some
days later and contains an important security fix that's remotely
exploitable in 2.6.16 and 2.6.17. The users of kmod-bar are in trouble now.

That's only one example of the problems with having multiple
kernel-modules in the repo. There are probably other variants from above
variants that can lead to trouble for our users.

Also: pushing kmods in extras at the same time the kernel is pushed to
updates will get hard.

CU
thl