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/