Panu Matilainen wrote :
> 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.
Well, the dkms approach is definitely best when it comes to enterprise
distributions (for which few or no kmod packages are available), custom
kernels or even rawhide.
> My only regret now is that I haven't looked at DKMS earlier :)
Same here. And I definitely owe Gary Lerhaupt (the original author
it seems) an apology, as he contacted me back in early 2004 to explain
what dkms was and asked me if I'd be interested in making it available
on freshrpms. But I never took the time to look at it :-(
Maybe my original questions are still relevant, as if other people here
are interested in dkms kernel module packages for their own needs, we
might as well agree on a common naming scheme and some common
guidelines.
For now, I've been leaving the dkms enabled sources in the "main"
packages for projects that contain more than just kernel bits (nvidia,
madwifi), but still providing "dkms-<name> = V-R". Simple modules I've
named "dkms-<name>" (dkms-tiacx, dkms-ipw3945).
As for the scriplets, I've just tried to add the rpm release to the
module version in order to make it easier to update a kernel module to
the same upstream version (i.e. a patched and fixed package), but I'm
not sure it's actually needed since I was still hitting other problems.
I'm still looking for the best solution to completely avoid corner
cases, make sure we never end up with a missing module, and handle all
possible updates correctly. This seems to work :
%post
# Add to DKMS registry
dkms add -m %{dkms_name} -v %{version}-%{release} -q --rpm_safe_upgrade
# Reuild and make available for the currenty running kernel
dkms build -m %{dkms_name} -v %{version}-%{release} -q || :
dkms install -m %{dkms_name} -v %{version}-%{release} -q --force || :
%preun
# Remove all versions from DKMS registry
dkms remove -m %{dkms_name} -v %{version}-%{release} -q --all \
--rpm_safe_upgrade
But I'd like to avoid the --force, though.. I just can't seem to find
a way around it.
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.31 0.26 0.26
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
