[Rpm-ecosystem] Writing a dnf plugin to better deal with out of tree kernel modules
vondruch at redhat.com
Thu Oct 6 10:39:02 UTC 2016
Dne 6.10.2016 v 12:26 Florian Festi napsal(a):
> On 10/06/2016 12:16 PM, Vít Ondruch wrote:
>> Actually is this really DNF issue?
>> DNF resolves the dependencies properly and installs what can be
>> installed. E.g. it keeps the kernel-core-4.6.1-1 which is compatible
>> with the module on the system as long as the module is installed, while
>> nothing prohibits installation of more recent kernel.
>> The problem is that the default boot loader entry is modified. Or that
>> kernel is blindly trying to load inappropriate modules.
> I disagree. It is the job of dnf and rpm to make sure all the desired
> packages get installed and having the matching modules installed with
> the new kernel is clearly what is the right thing to do here.
And I have to disagree here. If there was only possible to install
single kernel at the time, everything would work. E.g. kernel won't be
updated as long as there is no updated module. Everybody would be happy.
The kernel maintainers claims that kernels can be installed side by
side, but apparently this is not fully true. If there are kernel modules
build against specific version of kernel, they should be probably
installed into some versioned folder, so kernel 4.6.1 loads just modules
for kernel 4.6.1 and does not try to load modules for kernel 4.6.2. But
this is probably not true.
Of course part of the equation (at least for Fedora) is that 3rd party
kernel modules are not supported by kernel maintainers, so this is
non-issue for them.
> from an "but rpm (and dnf) follow the rules of the dependencies" POV
> does not cut it here. The question is how to craft the rules in a way
> they produce the desired result.
> If the module is not installed with the kernel no one is going to
> install it later, so having a smarter script for updating the boot
> loader won't cut it either.
More information about the Rpm-ecosystem