The commit message for
https://github.com/dell/dkms/commit/68b083eaa3f71c166adfece8e4f760e0cdf96185
says:
"Distributions know much better than us, what is the proper
way to package a DKMS module. Remove in-tree, semi-constantly
out-of-date code."
and a comment on https://github.com/dell/dkms/issues/70 says:
"Distribution specific packaging was severely broken for
most distributions and has been dropped in the latest
release."
This indicates that upstream has no interest in including or maintaining
distro-specific module packaging (and, indeed, mkrpm has been removed from
dkms too).
So, if upstream won't do it, perhaps debian's package of dkms should include
extra scripts providing the debian-specific functionality removed from dkms.
`dkms-mkbmdeb`, for example, could be a standalone wrapper script that uses
`dkms mktarball --binaries-only`. It could be based on the mkbmdeb code
removed from dkms.
ditto for `dkms-mkdeb` and `dkms-mkdsc` scripts.
Having separate scripts would also make it easier to keep dkms up-to-date with
upstream without having to patch it on every build.
craig
PS: not having to have the linux headers and a complete build environment on
every machine would be useful. My fastest machine, for example, can compile
the ZFS dkms module in a minute or so (per kernel version, and I typically
have at least two, current and previous on every machine) while my other
machines can easily take 15 or 20 minutes or more.
