Jesse Keating wrote:
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:
I'll draw a correlary for a moment and say that this happens in a lot of
places in the OS. If we update a package that has dependencies, and
some of the deps have to move, we have that problem today, no? Yes, the
kernel is a special case because it's more of a moving target and the
lack of internal APIs makes this harder, but it's something that we're
at least a little used to, even if it's to a lesser degree.
It might be enough to say "hey, if the kernel moves, it moves" and kmod
packagers have to follow.
* 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.
:P An opportunity to make some changes to RPM that enables this kind of
behavior?
* 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.
Right now there's no chance for them to work together. Set up a kmod
mailing list and get everyone on the same page? i.e. if you want to
maintain a kmod, get on the list and learn from others. I see this is a
chance to teach and bring a community closer together. We just need to
have a set of signposts to get people pointed in the right direction.
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
kernel modules that aren't in the upstream tree. I'm against including them
in standalone packages. These modules will not be available at install time
if in separate packages. If we care enough about the module and enough to
make it available at install time and as official packages/updates, we should
invest the time to get it into the kernel source package so that it is always
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.
I like the goal here - encouraging external people to participate - but
there's stuff that lives outside of the kernel today. The natural
reflection for that is separate packages, not addons into the kernel
package.
Yes, kmod has downsides. But on balance, doesn't the idea of enabling
external folks to add kernel modules and participate on an important
piece of our story worth the cost?
We'll learn as we go, and maybe we'll decide that it totally sucks.
(Failure needs to be OK, IMHO. If we're not failing we're not trying.)
Or maybe we'll learn that we need to change the way the package system
works for the kernel. But right now we can't even figure that out
because we're not even willing to try.
--Chris
_______________________________________________
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
