On Mon, 9 Oct 2006, Matthias Saou wrote:
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).
IIRC dkms was never *really* considered for the kernel module standard,
everybody was too busy arguing over uname-r in name, how to handle
debuginfo packages, what kind of macro magic to include, how many kernels
to build for in buildsys, how to teach the kmod scheme to buildsys etc.
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.
Amen brother :) I've been intending to have a look at dkms for a long
time, your post on the subject finally pushed me to actually do so. After
converting a couple of kernel module packages (internal stuff at work)
over to dkms, I'm simply loving it.
It's going to save me a helluva lot of time wasted on dealing with
rebuilding kernel modules for this-and-that kernel, please the
propellerheads running their own custom kernels and removes pretty much
the impossibility of trying to deal with kernel module dependencies in
some semi-correct way.
My only regret now is that I haven't looked at DKMS earlier :)
- Panu -
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
