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 _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
