[Fedora-packaging] Kernel modules packaged for dkms

[Matthias Saou]

Thorsten Leemhuis wrote :

[...]
> Well, dkms kernel-modules are not directly forbidden (at least it's not
> written down somewhere), but we choose to use kmod for kernel-module
> packages -- so they are not allowed AFAICS.

Then I'd like the people who pushed the kmod scheme to be accepted to
try and get it to be 100% functional ASAP, as the whole build server
side, to get automated rebuilds for all newly released kernels is quite
far from being implemented (unless I'm mistaken).

> And I don't think that we should change this as it helps people not much
> if we put two or more competing standards in Fedora Core/Extras.
> 
> > [...]
> 
> I'm not in general against rebuilding modules on the users system -- but
> it should be a option (e.g. for rawhide users), not the norm. I actually
> implemented a small script once that did what most users want -- simply
> rebuild the kmod-foo.srpm during boot up for the running kernel. I can
> work on it again if people are interested. It did what we are interested
> in in 5k -- dkms does a lot more what we don't need in 100k.

But dkms is quite solid, handles errors in a user friendly way...
and "just works" overall while keeping things simple. Sure, the actual
modules aren't in the rpmdb, but are easily identifiable (dkms.conf). I
would really prefer to have all kernel modules cleanly installed with
rpm, believe me, but I'm simply not comfortable with any of the current
packaging schemes.

I packaged acx100 as acx-kmod a few months ago :
http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod-common/
http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod/

Honestly, it stopped me from wanting to package more kernel
modules... :-( Yesterday, I packaged the newer tiacx as dkms-tiacx :
http://svn.rpmforge.net/svn/trunk/rpms/dkms-tiacx/

...and it made me want to package _more_ kernel modules! The most
painful part for kmod is getting a build environment ready to rebuild
the module for all the different kernels. The whole complexity of the
spec file filled with macros and stuff generated from the kmodtool
script doesn't help either. I'm sure that if I had wrote it, I wouldn't
see it as being so complex... but I didn't.

Anyway, I think you answered my questions : dkms packages aren't what
Extras want, so no need to bother.
For the time being, I think I'll stick with dkms for my own 3rd party
kernel modules, and move to kmod only once the framework to make
packagers' life easier will be ready.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6
Load : 0.22 0.38 0.70