Hi!
As promised two hours ago a solution to solve the remaining problem with
the current kmod standard.
== Problem ==
So the *only* (*1) remaining problem of the current kmod standard IMHO
and AFAICS is this case:
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-1.2.2.6.17-1.2157_FC5
kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed
to the repo
Yum will install:
kernel-2.6.17-1.2171_FC5
kmod-foo-1.2.2.6.17-1.2171_FC5
kmod-foo-1.3.2.6.17-1.2171_FC5 is pushed to the repo
Yum will install:
kmod-foo-1.3.2.6.17-1.2171_FC5
*and remove*
kmod-foo-1.2.2.6.17-1.2157_FC5
kmod-foo-1.2.2.6.17-1.2171_FC5
in the same transaction because the module location of
kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would
conflict. *This remove is the problem Axel complains about.*
Okay. This can be solved by having "uname -r" in the name and removing
the "Provides: kernel-module". But this creates other problems, e.g. at
least
- "new kernel-modules don't get installed without sepcial plugin"
- "uname -r is meaningless with the kabi stuff in RHEL".
A special yum-plugin could handle this two, but I prefer a different
solution.
(*1) -- if I missed anything please tell me
== Proposed solution ==
Install the kernel-module to
/lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
and remove the
"Requires: kernel<?kernel-flavour>-<?kernel-version>
Details:
We avoid the file conflicts noted in "Problem" above due to the
"VERSION-RELEASE" in the path. So yum will always install the module and
there won't be any conflicts.
But how will the kernel find the module there? "/sbin/weak-modules", the
script from the kabi stuff can create links to the proper places. It
does this already for modules installed in the proper place and kernels
that have the compatible kabi. It would be needed to adjust some
pathnames in the script, but that shouldn't be to hard.
And why remove the Requires? Well, with the kabi stuff it might happen
(not that often in Fedora, but on RHEL often) that a module runs fine on
a newer kernel. We wouldn't have to build a new module in that case.
*But* this requires would fire back because the kmod will get removed by
the depsolver when the kernel is was build for gets uninstalled.
Therefor it needs to be removed.
== Remaining problem ==
When do old kmods get removed from the system? Yes, that's a remaining
problem (that's why it's listed here (-; ). I'll talk to jcmasters and
jeremy and will work out a solution if we agree to work further on this
idea. I'm sure we'll find a solution. The installonlyn-plugin maybe
could handle that together with the kabi stuff. weak-modules could mark
a installed module as unused and the plugin (or another plugin) could
remove it later.
== EOF ==
CU
thl
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
