Comment 4 for bug 2020406

So we basically have two scenarios that we need to cover:
1) upgrade of a dkms package
2) upgrade of a kernel

For #1: We are supposed to fix all dkms packages in the archive to either a) compile properly for the new kernel or b) flag it as unsupported so that dkms build failures are ignored. If a dkms package upgrade results in a build failure, that's a legit failure unless it fails for an unsupported kernel.

If a dkms package is upgraded, first the current dkms module build is completely removed and later the upgraded dkms is rebuilt for all installed kernels (unless it was inactive for some installed kernels or /etc/dkms/no-autoinstall is present).

For #2: A kernel upgrade results in a rebuild of all installed (and active) dkms modules which can fail if they are unsupported or are old Ubuntu packages that haven't been purged. IMO this should not result in a kernel upgrade failure but it might be too complicated to detect this condition.

If a new kernel is installed, dkms autoinstall is called which rebuilds all installed dkms modules for the new kernel (unless /etc/dkms/no-autoinstall is present).

What kills us currently is #2 in combination with old and/or unsupported DKMS packages. Using the /etc/dkms/no-autoinstall mechanism to work around that is problematic as well because it skips the rebuild of upgraded dkms modules and we end up with an empty output of 'dkms status', i.e, no dkms builds at all.

ATM it's unclear to me if there's an ordering issue as well in case both the kernel and some dkms modules are upgraded (which upgrade happens first?). I think what we want is to always rebuild upgraded dkms modules (so we can't use no-autoinstall) but somehow don't fail a kernel upgrade in case of a resulting dkms build failure. Maybe downgrade that condition to a warning rather than an upgrade failure? It really is a dkms issue, not a kernel issue...