Move distribution specifics into the config

[evelikov]

As mentioned previously #323 (comment), ideally dkms will not know (or care) about the distribution it's run against.

Any specifics like DEST_MODULE_LOCATION overrides will be set in /etc/dkms/framework.conf and the user can override those with the usual /etc/dkms/framework.conf.d mechanism.

For this task, we should:

• construct a list of distro specific derivation(s), for each
• check if it's applicable - eg. do we need the collisions/archival for non Debian/Ubuntu platforms
• add a toggle in framework.conf, honour that in dkms
• add make install-foo variant which produces creates/uses the correct config for the given distribution

Nice to have:

• check with existing distros, if they use all the install-foo files, update as necessary
  • eg. Arch uses make install and manually removes kconf files and libdir

[evelikov]

From #329 we're currently running rpm indiscriminately which is causing problems. We should either:

• remove the offending calls, or
• use a conf knob to control that

[evelikov]

Another set of distro specific variations - module signing. In particular:

• location of sign-file and MOK key/cert
• deviation across Ubuntu/Debian of the update-secureboot-policy tool

At a glance, if we are to use modules_install itself aka #319 then we won't need to care about this.

[evelikov]

Moving the original module/collisions to standalone location:

• on all distros apart from Debian/Ubuntu we backup the original module (on build) and restore it on uninstall

Might be worth tracking down the reason behind this variance and removing it, in the mid/long run. At least initially preserving the behaviour seems like a good first step.

[evelikov]

The above are the distro-specific variations we have so far, although others may emerge at some point.

They don't have to be fixed all together/in a single PR. So if anyone is bored and like to write some bash - patches welcome o/

[HanabishiRecca]

Moving the original module/collisions to standalone location:

• on all distros apart from Debian/Ubuntu we backup the original module (on build) and restore it on uninstall

Might be worth tracking down the reason behind this variance and removing it, in the mid/long run. At least initially preserving the behaviour seems like a good first step.

It is very unclear why. The kernel simply traverses filesystem in alphabetic order, afaik. Which means not removing the original module leads to undefined behavior.
updates is lower than all existing kernel tree dirs except virt. I.e. it will never replace original modules except they are in virt.

[evelikov]

@HanabishiRecca the original is stored outside of the normal search path. Note that the kernel does not care about any of this - kmod does all the path/priority handling as well as loading.

The ultimate goal here is not to fix everything that's off with dkms, but migrate from a bunch of "running_distribution" hacks to a data/config driven flow.