On Wed, 2006-09-20 at 09:49 -0400, Jesse Keating wrote: > On Tuesday 19 September 2006 16:04, Toshio Kuratomi wrote: > > Arguments against kmods: > > * It makes the job of diagnosing kernel bugs harder as there could be > > extra kmods on top of a stock fedora kernel. > > * kmods and kernels could go out of sync. > > Wrong. By nature, kmods and kernels will ALWAYS get out of sync. This will > prevent security updates from installing on a users system until the kmod > developer gets around to rebuilding the module. This is a REALLY poor user > experience. Further arguments against kmods include: > * no sane way to package them, everything is just a hack > * no sane way to manage installation/upgrades. RPM just does not mesh well > with the way that kmods need to operate. The way rpm handles kernel is a bit > hacky, multiple releases of a package installed at the same time. Throwing > addon packages to this in the mix makes the whole RPM system spiral downhill > in a hurry. > * kmod developers are largely out of the loop in kernel developments and > directions of the kernels. This is somewhat solveable but hard to keep up > especially if we allow more and more kmods in where the packare is just that > a packager, and not a kernel developer. > > > > > Arguments for kmods: > > * It makes the job of the end-user easier because they need the > > functionality anyway and will get it from another source if necessary. > > * It makes the job of the kernel developers easier because they at least > > know the end-user is using a kmod from fedora-extras (and can ask: "if > > you rpm -qa |grep kmod does that turn up anything?" whereas a from > > source kmod would not leave that evidence.) > > Um, lsmod is pretty easy to run. And its quicker than rpm -qa. This argument > is bunk. > > > * Fedora is a home for all open source software. Open source kmods are > > part of that definition. > > Yes, however there is no reason why these kmods couldn't live IN the kernel > src.rpm and not in separate packages. I'm not against Fedora including Yes, there is. DaveJ said no, and I don't blame him. If it lives IN the kernel src.rpm, then bugs get filed against that and the problem lies back on the Core kernel developers. > released at the same time and gets the same attention. The real challenge is > making it easier for the community to assist in the kernel development, not > in creating subpackages of modules that only makes it more complex and > difficult. Considering the number of people that work on it now, and the things needed to keep in sync, I find that to be just as complex as keeping them in their own package. For example, you do _not_ want to hold up a Core kernel security fix because someone from the community has a driver that needs updating. It's the same damn argument, only now it prevents the security fix from getting out for _everybody_ not just the ones using said module. josh _______________________________________________ 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
