Repository navigation
Move distribution specifics into the config #328
Description
Activity
From #329 we're currently running
rpmindiscriminately which is causing problems. We should either:- remove the offending calls, or
- use a conf knob to control that
Another set of distro specific variations - module signing. In particular:
- location of
sign-fileand MOK key/cert - deviation across Ubuntu/Debian of the update-secureboot-policy tool
At a glance, if we are to use
modules_installitself aka #319 then we won't need to care about this.- location of
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.
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/
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.
updatesis lower than all existing kernel tree dirs exceptvirt. I.e. it will never replace original modules except they are invirt.@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.
As mentioned previously #323 (comment), ideally dkms will not know (or care) about the distribution it's run against.
Any specifics like
DEST_MODULE_LOCATIONoverrides will be set in/etc/dkms/framework.confand the user can override those with the usual/etc/dkms/framework.conf.dmechanism.For this task, we should:
framework.conf, honour that in dkmsinstall-foovariant which produces creates/uses the correct config for the given distributionNice to have:
install-foofiles, update as necessarymake installand manually removes kconf files and libdir