Jesse Keating wrote:
> But we didn't ban non-upstream modules. Instead we made the kernel team
> the gateway. If the module is good enough to provide to Fedora users,
> it's good enough to be in the kernel package proper. This gets around
> the build timing / ordering issue, it prevents newer kernels from
> causing the module to stop building, it removes the need for gross
> yum/rpm hacks to handle the packages properly, it removes the need to
> re-create the initrd after a module update, so on and so forth.
But the kernel maintainers are extremely selective in what they want to
build as part of the kernel package, and I don't really blame them.
Allowing other maintainers to maintain their modules separately means they
keep most of the burden of keeping them up to date, and they can even be
temporarily unbuildable in Rawhide without breaking the kernel, we only
need them working when a release or a kernel update to a release is made.
It also means users make a concious decision to install the module, it
doesn't just magically break their system, so it's much less risky to ship
experimental or poorly-maintained modules that way.
If the kernel maintainers were willing to carry appropriately-licensed
modules like kqemu, current Ralink drivers (I know they're buggy, but it's
better than not have the hardware work at all) etc., kmod packages would
not be needed, but there are good reasons not to ship that stuff within the
kernel (for example it can lock up systems where it's not really needed -
putting the module into a separate package means only people who asked for
it got what they asked for), yet there are also good reasons to have it
available. Thankfully RPM Fusion is providing that service, but it would
make more sense to have the stuff in Fedora as there are no licensing or
patent issues with it.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
