This is not a story I planned to publish next, but burning my brain over this recently led me to the conclusion it makes sense to document my findings for a wider audience.
Till version 2.8 Dell’s DKMS had built-in features to fabricate RPMs and .deb packages. Apart from the fact, that support for Debian was broken for years, it was straightforward for everyone to cook a DKMS package with some Linux Kernel’s driver code, just cook your dkms.conf and fire dkms mkdeb (or dkms mkrpm). While kind of useful, that wasn’t precisely a proper way to build Debian packages, especially as it hasn’t been using natural sequences debhelpers would normally use.
The article assumes you have a source code of the driver that builds and it’s proven to work. What I describe here is only the process of preparation of the package, not writing and compiling the driver.
Structure of proper Debian Package
In general, there are two ways how a Debian Package is machined into an installable .deb file handled by dpkg or apt:
nativeis the mode where both the source and the package control files are present in the same tree,quiltis the mode where the source is supposed to be pulled from upstream¹, patched with patch series (byquilt) then built and packed.
