[Slackbuilds-users] Packaging kernel modules with DKMS

fsLeg fsleg at t-rg.ws
Tue Jun 23 10:31:12 UTC 2026


This is not a pressing issue, but it would be nice to have an understanding for the future.

Slackware-current now has DKMS. While not applicable for 15.0, SBo has a script for DKMS, so it's still kinda relevant. My question is, how do you package kernel modules to make use of DKMS?

The building part is not a problem. My problem is with doinst.sh and especially douninst.sh scripts. The proper way of removing a module installed with DKMS is with `dkms remove` command. But douninst.sh is run after the package is removed, leaving dkms-tree for the module in a broken state and modules still in /lib/modules. So removing the package that installed a module won't remove the module itself and leave a mess in /var/lib/dkms which is not good. What should be the proper way of addressing that?

I outlined my current workaround in an LQ post: <https://www.linuxquestions.org/questions/slackware-14/dkms-now-in-current-4175765154/page3.html#post6638610> Is something like this acceptable? Am I missing something? Or should we ask our BDFL to add support for pre-removal scripts so `dkms remove` could be properly called?

Another workaround was suggested by LuckyCyborg immediately after: install the source tree into a temporary location and move it to a proper one in doinst.sh. While I like its simplicity, I don't like that it makes the installation log in /var/log/packages useless. Or would it be acceptable? Because this workaround allows the use of `dkms remove` in douninst.sh.

Or am I complicating things too much and should just stick to what is being done currently even after 15.1 releases? But it is rather annoying to manually rebuild all external modules by hand on every kernel upgrade. And DKMS isn't something complex, it's just a bash script that automates this part.


More information about the SlackBuilds-users mailing list