packaging: accept the DKMS module list as a build input

[Christopher Obbard (obbardc)]

The set of bundled out-of-tree modules is currently declared twice in the packaging tree: once in debian/dkms-modules and once in the Build-Depends of debian/control.in. Both have to be edited together and neither can differ between kernel variants or deliveries.

Take the list as one comma-separated input instead: prepare-source.sh --dkms, build-kernel.sh --dkms, or DKMS_MODULES= passed straight to "debian/rules prepare" and generate both files from it. control.in gains a @DKMS_BUILD_DEPENDS@ placeholder that expands to ", dkms, -dkms..." (nothing at all for an empty list) and dkms-modules becomes a generated file written on every prepare, so a missing manifest still means prepare never ran rather than an empty module set.

Entries are validated at prepare time: package-name stem, no -dkms suffix, no duplicates.

Nothing is bundled unless a build asks for it; CI passes the list from the dkms field of ci/build-matrix.json.

This is the sister-PR of #89; both are needed to land at the same time.

[Bjordis Collaku (bjordiscollaku)]

Nice, this is the piece #89 was missing, and generating both from one variable is the right call. The @DKMS_BUILD_DEPENDS@ placement handling the empty case without a dangling comma, and leaving dkms itself out when nothing is bundled, is a good detail.

One thing: debian/dkms-modules is still tracked. The .gitignore entry and the README's "Generated (gitignored)" line have no effect on a file already in git, so make -f debian/rules prepare DKMS_MODULES=... in a clone leaves the tree dirty against a stale committed copy. Every other generated file here is untracked. Wants a git rm debian/dkms-modules in the same commit?

[Bjordis Collaku (bjordiscollaku)]

Rebase looks good. debian/dkms-modules is still tracked though, so the gitignore entry and the "Generated (gitignored)" line in the README don't take effect yet. Just wants a git rm on it.