[aur-general] Packaging with DKMS support
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/
On Thu, 2011-03-24 at 12:16 +0900, Jason Melton wrote:
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].
Quick problem, what happens when the kernel version updates? For example modules are currently in /lib/modules/2.6.38-Arch/kernel/* (from [testing]) but when 2.6.39 comes out the location changes, and the package needs to be reinstalled in any case.
2011/3/24 Ng Oon-Ee <ngoonee@gmail.com>
On Thu, 2011-03-24 at 12:16 +0900, Jason Melton wrote:
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].
Quick problem, what happens when the kernel version updates? For example modules are currently in /lib/modules/2.6.38-Arch/kernel/* (from [testing]) but when 2.6.39 comes out the location changes, and the package needs to be reinstalled in any case.
Jason's solution just suits for the version changes form 2.6.38.* to 2.6.38.*,the location of the driver doesn't need to be relocated.But if the major version has changed for example from 2.6.38 to 2.6.39,the PGBGUILD should be re-released to place the driver in the new place.Alternatively,may be do some hack to the drivers pacman db files?
2011/3/24 Ng Oon-Ee <ngoonee@gmail.com>:
On Thu, 2011-03-24 at 12:16 +0900, Jason Melton wrote:
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].
Quick problem, what happens when the kernel version updates? For example modules are currently in /lib/modules/2.6.38-Arch/kernel/* (from [testing]) but when 2.6.39 comes out the location changes, and the package needs to be reinstalled in any case.
Hello, In the case of the non-DKMS user, there is no change - nor should there be - they always need to reinstall the package anyway. This is what we want, because we don't want to change how things behave for the non-DKMS user. In the case of the DKMS user, DKMS will rebuild and install the driver in the correct location for the new kernel. This will happen even if the move is from 2.6.38.* to 2.6.39.* - or whatever change there is. The "DEST_MODULE_LOCATION[0]" tells DKMS where to place the built driver, and for this line "/kernel" is a reference to /lib/modules/<kernelversion>/kernel. A drawback is that, in this case DKMS will create a file that is no longer tracked by pacman. But, since an updated package must be released soon anyway for the non-DKMS users, this situation will not last long. An alternative would be updating the information in the pacman db, but that's really pushing things I think. == Further note == There was an error in the install file, where I left out the dkms stuff for post_upgrade. I think everyone can get the point without it, but I'll post a corrected version just in case.[1] [1]http://paste.pocoo.org/show/358794/
On 24.03.2011 08:50, Jason Melton wrote:
2011/3/24 Ng Oon-Ee <ngoonee@gmail.com>:
On Thu, 2011-03-24 at 12:16 +0900, Jason Melton wrote:
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].
Quick problem, what happens when the kernel version updates? For example modules are currently in /lib/modules/2.6.38-Arch/kernel/* (from [testing]) but when 2.6.39 comes out the location changes, and the package needs to be reinstalled in any case.
A drawback is that, in this case DKMS will create a file that is no longer tracked by pacman. But, since an updated package must be released soon anyway for the non-DKMS users, this situation will not last long. An alternative would be updating the information in the pacman db, but that's really pushing things I think.
Packages that contain kernel modules should contain something like depends=(kernel26>=2.6.37 kernel26<2.6.38) so unless you use -d or there is an updated version of the package you shouldn't be able to update the kernel. -- Florian Pritz -- {flo,bluewind}@server-speed.net
On Thu, Mar 24, 2011 at 11:24 PM, Florian Pritz <bluewind@server-speed.net> wrote:
On 24.03.2011 08:50, Jason Melton wrote:
2011/3/24 Ng Oon-Ee <ngoonee@gmail.com>:
On Thu, 2011-03-24 at 12:16 +0900, Jason Melton wrote:
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].
Quick problem, what happens when the kernel version updates? For example modules are currently in /lib/modules/2.6.38-Arch/kernel/* (from [testing]) but when 2.6.39 comes out the location changes, and the package needs to be reinstalled in any case.
A drawback is that, in this case DKMS will create a file that is no longer tracked by pacman. But, since an updated package must be released soon anyway for the non-DKMS users, this situation will not last long. An alternative would be updating the information in the pacman db, but that's really pushing things I think.
Packages that contain kernel modules should contain something like depends=(kernel26>=2.6.37 kernel26<2.6.38) so unless you use -d or there is an updated version of the package you shouldn't be able to update the kernel.
True, but this doesn't take away any of the benefits of DKMS support.
On 24 March 2011 09:16, Jason Melton <jason.melton@gmail.com> wrote:
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].
Good job. I personally have no objections to standardising this. All it would require is for packagers to incorporate a bit more typing for module packages only. If we have a library system in place for makepkg/pacman this could've been templated for use with one-liners.
participants (5)
-
Florian Pritz
-
Jason Melton
-
Ng Oon-Ee
-
Ray Rashif
-
郑文辉