DKMS package guidelines

Here are some guidelines to follow when creating a DKMS package.

Arch package guidelines

32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – Shell – VCS – Web – Wine

Package name

DKMS packages are named by appending "-dkms" to the original package name.

The variable $_pkgname is often used below $pkgname to describe the package name minus the "-dkms" suffix (e.g. _pkgname="${pkgname%-*}")

Dependencies

Add dkms to depends array. This is important because this will provide tools and hooks that will rebuild the kernel driver provided by the -dkms package whenever the kernel is updated.

Do not include linux-headers – or any other Linux header package – to the PKGBUILD. These headers are already listed as optional dependencies of dkms and each kernel package has its own header package, so including header package dependency in the -dkms package is both unnecessarily redundant and restricting.

Source location

The package should install the kernel module's source files into:

/usr/src/PACKAGE_NAME-PACKAGE_VERSION

where PACKAGE_NAME and PACKAGE_VERSION are the kernel module's name and version.

It is highly recommended to set PACKAGE_NAME with the value of $_pkgname (See #Package name), and PACKAGE_VERSION with $pkgver.

Note: There is no need to build the kernel module's sources file nor install them; this is done automatically whenever the Linux kernel is updated thanks to a pacman hook in dkms.

Patching

The sources can be patched either directly in the PKGBUILD or through .

If patching through , make sure to install the patches into directory and to add a PATCH[number]=patch_filename for each patch to be applied, replacing with a incremental value starting at . See dkms(8) § DKMS.CONF for more information.

Module loading automatically in .install

Do not use .install file to load or unload modules. Leave it to the user, since there is a possibility a module may crash when loaded.

Also do not call dkms as it is automatically done via pacman hook provided by dkms. This hook runs and leaving no manual task for the package maintainer.

Example

Here is an example package that edits according to the package name and version, and install module blacklist configuration file.

For other example of (real) packages, search -dkms in official repositories and -dkms in AUR.

.install

This example shows a message on post-install and post-upgrade that suggests unloading a conflicting module () and then loading this package's module () for immediate use, when the user do not want to reboot the system at this moment.

Module blacklist conf

When it is known that conflicts with this package's module, it should be blacklisted:

example-dkms.conf

blacklist example-conflicting-module

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.