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