kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting)

[Jeff Spaleta]

> > The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible.
>
> Same for dkms, as modules might break if the api changed.

slightly less complex for dkms, because with dkms you don't have to
deal with synchronously building the modules on the central build
system. You package dkms source payloads and you let dkms attempt to
build the modules locally as soon as a new kernel is installed. (dkms
can even build rpms locally too to populate the rpmdb for tracking
purposes)

I think dkms works as a piece of technology as far as it can. The
question really is, would providing dkms source payloads in Fedora
help drive mainlining of kernel modules or does it discourage the
necessary upstream discussions.  If providing dkms source payloads can
help move things into upstream via feedback, then I'm all for it. But
if its just going to be a way for people to get around the hard work
of getting a module upstreamed, then I'm not for it. Which is why I'd
be interested in setting an explicit expiration date for any dkms
payload. I don't want to see this stuff linger as an external module
indefinitely. I want to see progress towards adoption, and if there's
no progress than we drop the dkms payload package.

-jef