[aur-general] Packaging with DKMS support

[Jason Melton]

Hello,

Over on the rtl8192se package[1], we have been discussing how to best
support DKMS in packaging (at the AUR level), and I would like to ask
for wider and more experienced comments. I have put my thoughts here
and in more detail on my personal Arch wiki page[2].

Thank you.

= DKMS Overview =
In case anyone doesn't know, DKMS[3] is "Dynamic Kernel Module
Support", a Linux technology from Dell that basically re-builds
drivers for you when the kernel changes.

Big Pro: It is a pain to remember to rebuild some drivers after a
kernel upgrade or change, especially crucial drivers like wireless or
video card. DKMS automates this process, is robust and used by many
distros.

Big Con: It complicates the packaging process, and introduces an
additional "layer".

Primarily, I hope that I can show the Con can be greatly reduced, and
the Pro is so valuable it should be considered the suggested way to
build kernel modules.
Secondly, I hope to get feedback from more experienced packagers.

= Packaging DKMS =

DKMS is great. I'd like to see it incorporated more in Arch. One way
to do so it to provide robust and useful DKMS-enabled packages as an
alternative to the "vanilla" driver packages. Another way would be to
build in DKMS in the driver package by default, and only "activate" it
if the user has dkms on their system. In either alternative, more
explicit and comprehensive packaging guidelines would be beneficial.

Right now, when it comes to DKMS and the AUR, we generally have 2
packages: a "vanilla" package (ex: rtl8192se) and a "DKMS enabled
package" (ex: dkms-rtl8192se).[4]

My proposal is to package DKMS support into the "vanilla" package, and
let the package .install file determine whether to let DKMS control
the drivers or not. In this proposed scenario, there need only be one
driver package.

Here are the sample files:
A sample PKGBUILD.[5]
A sample install.[6]
A sample dkms.conf.[7]

Here is basically what happens: The package installs like normal, with
the addition of the source code. In the .install file, if DKMS is
present on the system, we set it up for DKMS to take over the drivers,
calling one dkms_<event handler> from each needed corresponding
"vanilla" <event handler>, and overwriting the installed driver. Since
DKMS will only overwrite a file we just installed, pacman can still
track what package owns the file. We do the reverse when uninstalling.

= Pros =
DKMS means the user need not remember to rebuild drivers after a
kernel update or for a different kernel running on the system.
1 package can support DKMS and non-DKMS users
If there are clear guidelines for DKMS packaging in AUR, more modules
will pick it up, enriching Arch

= Cons =
Slightly more complicated PKGBUILD
Source code installed (although many users keep the package on disk as
it is now because they need to manually rebuild the package after an
update)
More complicated install file (but still template-able and very
similar to the existing install file)

= A further note =
Everything across all the necessary files (PKGBUILD, install,
dkms.conf) can be "templated" so the packager need not manually update
the names/versions across multiple files. I have a very simple example
script that generates the install file and the dkms.conf from the
information in the PKGBUILD and a install.template [8].

= Conclusion =
DKMS reduces the complexity of knowing what package a user should
install for what kernel, and remembering to rebuild modules after a
kernel change by moving that complexity into the packaging process.

DKMS offers a great benefit to users at a small cost to packaging and
should be made a recommended practice when packaging kernel drivers.

Again, thank you for taking the time to read this and I welcome your feedback.


[1]http://aur.archlinux.org/packages.php?ID=34281
[2]https://wiki.archlinux.org/index.php/User:Ushimitsudoki
[3]http://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support
[4]http://aur.archlinux.org/packages.php?ID=47330
[5]http://paste.pocoo.org/show/358740/
[6]http://paste.pocoo.org/show/358741/
[7]http://paste.pocoo.org/show/358742/
[8]http://paste.pocoo.org/show/358745/