> > 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
