Re: kernel modules in RPM Fusion; we need a decision

> To me, kmod can only be acceptable if AND ONLY IF the rebuild of the > kmod packages is automated based on a RSS feed coming from Koji or > Bodhi of some sort. i.e. guarantee a zero-time dependency break from > kernel updates. Impossible -- we want to sign rpms manually (juest like Fedora does; they just showed why that is important). A lot of the other tasks for rebuilding kmods are scripted, but not fully automated yet -- I have a long todo list for RPM Fusion and other things seem to be way more important to me.

BTW, why do you care how quick kmod get released? You seem to be in favour of dkms. It's counterpart is akmod so feel free just use that -- the akmods won't be re-released when a new kernel shows up. And btw, livna was quite good in shipping new kmods just-in-time for new kernels. It was only a real problem recently when the buildsys was down for a few days. Kmod on the other hand provide an addition benefit that we would not have with dkms: pre-compiled modules. That for example is important for small machines for example -- a few livna users with the first-gen Asus Eee PC for example were really glad that they got a pre-compiled madwifi-kmod in livna-testing. Most of those users didn't want dkms or akmods as they didn't want to install gcc and its deps on the samll SSD; the users afaics also did not want to wait for the module to compile (which takes quite a bit longer on small machines like the Eee PC).