Dynamic Kernel Module Support
Dynamic Kernel Module Support allows one to compile and install kernel modules without recompiling the entire kernel.
These are just my own scratch notes on packaging with DKMS support, an area I find interesting and under-appreciated in Arch. Eventually, I'd like to see better/more official guidelines for DKMS-enabled packages in Arch.
Some Good References
- Dell's DKMS man page Official site.
- Ubuntu's DKMS man page (Documents some officially un-documented bits.)
Here are some guidelines that I am trying to follow.
Since it is likely that the DKMS package duplicates a non-DKMS package, I am prefixing the non-DKMS package with "dkms-". If I were to package something that didn't have a non-DKMS counterpart, I would still use the "dkms-" prefix.
Where should source go?
DKMS by default uses /usr/src/, but [namcap] complains that is a non-standard directory. (Even though the FHS reference namcap uses states that /usr/src is "optional". One could place the source in /opt/<package> and then sym-link it (which is what some non-DKMS packages do.)
Currently, I am just putting the source in /usr/src/<package> under the "true package name" (which is usually the PKGBUILD $_pkgname variable, which is the $pkgname minus the "dkms-" prefix)
Where should patches be applied?
One could patch the source either in the PKGBUILD or through DKMS. Since non-DKMS packages patch from the PKGBUILD, and to keep the DKMS PKGBUILD as close to the non-DKMS version, I am patching in the PKGBUILD.
Should the .install file attempt to modprobe/rmmod the module?
I don't know which way to go on this. I like the idea of the module coming up once the package is installed, but based on what I have seen, most packages do not do this. Right
How to create .install / dkms.conf files?
Try to avoid updating things like version numbers in multiple files. Try to avoid cluttering up PKGBUILDs/.install files with DKMS-specific stuff. (This keeps them closer to the non-DKMS files).
I've just started using a simple bash script to create the dkms.conf file and to replace text in an install.template file. This leads to much cleaner and easier to understand files.
DKMS breaks the ABS
Sort of, yes. The problem is that the resulting modules don't belong to the package, so pacman can't track or report on them.
I don't think that's a show-stopper, but it probably puts DKMS out on the fringe a bit. There is some talk about pacman adding similar support through pacman hooks. . I think you could might "fake" the ownership, by installing the module as normal (or even a "dummy" file) and just letting DKMS overwrite it.
This is beyond me right now.
As mentioned earlier, namcap complains if you put source in /usr/src. Also, namcap can not detect that dkms is a dependency. (I guess maybe it's not technically a dependency, but...)
Basically, take the dependencies of the non-DKMS version, add 'dkms' and remove 'kernel-headers' (since dkms depends on that)