DKMS 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
创建一个新的DKMS包时，可以参考下面的指导方针。
包名
DKMS的包的命名方式是：原始包名加"-dkms"后缀。
通常在 $pkgname 后面使用 $_pkgname 记录不包含 "-dkms" 后缀的软件包名 (例如 _pkgname=${pkgname%-*}). 这样可以在原始的软件包 PKGBUILD 和 DKMS 编译文件之间保持相似性。
依赖
依赖的包应该是原来软件包的基础上，加上 dkms， 删除 linux-headers，内核头文件已经是 dkms 的可选依赖。
源代码构建位置
构建模块所需源代码需要放在（这是DKMS构建模块时使用的默认目录）：
/usr/src/PACKAGE_NAME-PACKAGE_VERSION
在软件包目录，要包含一个 dkms.conf 配置文件，告诉 DKMS 如何编译。这个配置文件需要包含：
PACKAGE_NAME- 实际的项目名称，通常使用$_pkgname或$_pkgbase.PACKAGE_VERSION- 通常使用$pkgver.
打补丁
为内核模块源代码打补丁既可以直接在PKGBUILD中进行，也可以通过dkms.conf来进行。
.install 中模块的自动加载
模块的加载和卸载必须由用户自己来执行，设想一下，某个模块可能在加载的时候崩溃。
现在已经不需要单独执行 更新内核模块的依赖。Pacman 现在会自动执行 和 钩子。 会确保过程结束时执行 。 依赖 (针对当前内核编译源码)，build 依赖 dkms add (添加从 到 的链接)。
namcap 输出
namcap （它会试图检查一个包中的一般性错误和不符合标准的设定）在任何包中最好至少使用一次。然而，namcap至今仍然没有针对DKMS的特殊方针做更新。
例如，默认情况下,DKMS使用/usr/src/，不过Namcap认为这不是一个标准目录，不符合这个reference。
例子
这儿有个根据包名字和版本来对dkms.conf进行编辑的例子。
.install
pacman 已经支持 DKMS 钩子，不需要在 .install 文件中指定 DKMS 额外配置，pacman 会自动执行 和 。