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
On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote:
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.*
I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also remove kmod-foo-1.2.2.6.17-1.2157_FC5? Wouldn't that be in a different module tree?
== 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.
Also, with the kabi stuff, the Requires should get done automatically to an ABI version. If the next kernel has an ABI change, and you rebuild the module, thats cool, it picks up the new ABI in the automatic Requires. No manual intervention.
I would _really_ like to get JCM involved in this discussion, especially on the proper place to drop these modules so that a respin for one kernel won't remove modules from an older kernel.
Jesse Keating schrieb:
On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote:
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.*
I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also remove kmod-foo-1.2.2.6.17-1.2157_FC5? Wouldn't that be in a different module tree?
Well, normally it's a "install transaction" but when there is a potential file conflict it's changed to a "upgrade transaction" afaik -- and that will remove the old kmod as well because both old kmods have the same packagename.
== 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.
Also, with the kabi stuff, the Requires should get done automatically to an ABI version. If the next kernel has an ABI change, and you rebuild the module, thats cool, it picks up the new ABI in the automatic Requires. No manual intervention.
That would solve the problem nicely.
I would _really_ like to get JCM involved in this discussion, especially on the proper place to drop these modules so that a respin for one kernel won't remove modules from an older kernel.
+1
CU thl
/me going to bed now soon
On Mon, Aug 14, 2006 at 08:47:18PM +0200, Thorsten Leemhuis wrote:
Jesse Keating schrieb:
On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote:
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.*
I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also remove kmod-foo-1.2.2.6.17-1.2157_FC5? Wouldn't that be in a different module tree?
Well, normally it's a "install transaction" but when there is a potential file conflict it's changed to a "upgrade transaction" afaik -- and that will remove the old kmod as well because both old kmods have the same packagename.
This is not correct. The current implentation will install the new module and add an erase transaction element for the old module requiring the same kernel.
== 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.
Also, with the kabi stuff, the Requires should get done automatically to an ABI version. If the next kernel has an ABI change, and you rebuild the module, thats cool, it picks up the new ABI in the automatic Requires. No manual intervention.
That would solve the problem nicely.
I would _really_ like to get JCM involved in this discussion, especially on the proper place to drop these modules so that a respin for one kernel won't remove modules from an older kernel.
+1
CU
Generally, kabi sucks less, so +1
Right now I use the Requires: kernel-i686 = 2.6.14-1.1776_FC4 to figure out what kernel we match, but that's easy to fix.
Jack
thl
/me going to bed now soon
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Monday 14 August 2006 16:11, Jack Neely wrote:
Well, normally it's a "install transaction" but when there is a potential file conflict it's changed to a "upgrade transaction" afaik -- and that will remove the old kmod as well because both old kmods have the same packagename.
This is not correct. The current implentation will install the new module and add an erase transaction element for the old module requiring the same kernel.
Wait, stop the presses.
Isn't this the "root" of the problem that Axel is complaining about, that the kmod version of doing things will cause old modules for old kernels to get removed? If this isn't the case, then why are we talking about replacing the current standard?
On Mon, Aug 14, 2006 at 07:57:17PM -0400, Jesse Keating wrote:
On Monday 14 August 2006 16:11, Jack Neely wrote:
Well, normally it's a "install transaction" but when there is a potential file conflict it's changed to a "upgrade transaction" afaik -- and that will remove the old kmod as well because both old kmods have the same packagename.
This is not correct. The current implentation will install the new module and add an erase transaction element for the old module requiring the same kernel.
Wait, stop the presses.
Isn't this the "root" of the problem that Axel is complaining about, that the kmod version of doing things will cause old modules for old kernels to get removed? If this isn't the case, then why are we talking about replacing the current standard?
-- Jesse Keating Release Engineer: Fedora
The fedorakmod.py implementation only removes old kernel modules when you have upgraded the kernel module within the same kernel version. Otherwise the packages would have file conflicts.
So if you have installed:
kmod-foo-1.2.2.6.17-1.2157_FC5 kmod-foo-1.2.2.6.17-1.2158_FC5 kmod-foo-1.2.2.6.17-1.2159_FC5
and Yum has kmod-foo-5.2.2.6.17-1.2158_FC5 in the repo you wind up with the following set installed:
kmod-foo-1.2.2.6.17-1.2157_FC5 kmod-foo-5.2.2.6.17-1.2158_FC5 kmod-foo-1.2.2.6.17-1.2159_FC5
as kmod-foo-1.2.2.6.17-1.2158_FC5 and kmod-foo-5.2.2.6.17-1.2158_FC5 contain the same file paths. This is nicely solved by kabi.
Jack
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Mon, Aug 14, 2006 at 07:57:17PM -0400, Jesse Keating wrote:
On Monday 14 August 2006 16:11, Jack Neely wrote:
Well, normally it's a "install transaction" but when there is a potential file conflict it's changed to a "upgrade transaction" afaik -- and that will remove the old kmod as well because both old kmods have the same packagename.
This is not correct. The current implentation will install the new module and add an erase transaction element for the old module requiring the same kernel.
Wait, stop the presses.
Isn't this the "root" of the problem that Axel is complaining about, that the kmod version of doing things will cause old modules for old kernels to get removed? If this isn't the case, then why are we talking about replacing the current standard?
The root of the problem is the 5 workaround steps I listed in another mail.
a) You start with the kmod scheme (merging two evrs together ) and find out that this way you can only support exactly one kernel b) It looks like kmods are like kernels, e.g. always coinstall, adding Provides: kernel-module support to yum to tag all such packages as coinstallable. c) You find out that kmod are by design neither "upgrade", nor "coinstallable" class of packages. rpm/yum only know these two kind of packages. So now
c1) yum installs only kernel modules for the latest module version and the latest kernel. No newer module version is installed for older kernels even if they are available in the repo. That's because yum only coinstalls *the* newest which is a merged evr scheme is moduleversion/kernelversion. yum cannot guess the two dimensional background of the problem since it only sees one common evr.
c2) yum coinstalls kernel modules for the same kernels bailing out with file conflicts
d) no problem, we have workarounds for workarounds for workarounds [...] Why not undo the "damage" that bad yum inflicted on us for being rpm compatible. Let's detect those coinstalls-that-should-be-none and start removing package in the plugin.
Oops still not addressing the bug with yum + plugin not seeing kmods for previous kernels anymore at all!
Where would we be if we wouldn't start adding more workarounds, so let's take a look into the crystal ball
e) Jack persuades Seth to change the "kernel-module" yum-core behaviour from "kernel{,-flavour}" behaviour. The latter really wants yum to only see the latest version and coinstall it, but for the former we want yum to see them all and coinstall newer kernel modules for old kernels, too, e.g. trying to fix c1)
f) Now suddenly yum sees too much, it also sees kernel modules that have a newer one installed (which may happen even today see [1]), so we need to remove these from the ongoing transaction
g) It turned out that only some kernel modules are trivial enough to be removed on the fly in the transaction set. Many kernel modules have package dependencies that pull in or push out other packages. An old kernel module for instance "wrongly" selected for updating and later discarded by the plugin had pulled in incompatible firmware or it's older userland component.
Now how to detect which package was pulled in or pushed out by the unwanted packages in the transaction set? Let's think of a hack and find a workaroung later, the alphabet is long enough.
Hm, the alternative scheme only needed 99 lines of python for full unbroken yum support and no further yum-core manipulation?
Hm, ...
Hm, ...
Added to http://fedoraproject.org/wiki/AxelThimm/kmdls, search for pandora's box.
On Tue, Aug 15, 2006 at 02:22:28AM +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 07:57:17PM -0400, Jesse Keating wrote:
On Monday 14 August 2006 16:11, Jack Neely wrote:
Well, normally it's a "install transaction" but when there is a potential file conflict it's changed to a "upgrade transaction" afaik -- and that will remove the old kmod as well because both old kmods have the same packagename.
This is not correct. The current implentation will install the new module and add an erase transaction element for the old module requiring the same kernel.
Wait, stop the presses.
Isn't this the "root" of the problem that Axel is complaining about, that the kmod version of doing things will cause old modules for old kernels to get removed? If this isn't the case, then why are we talking about replacing the current standard?
The root of the problem is the 5 workaround steps I listed in another mail.
a) You start with the kmod scheme (merging two evrs together ) and find out that this way you can only support exactly one kernel b) It looks like kmods are like kernels, e.g. always coinstall, adding Provides: kernel-module support to yum to tag all such packages as coinstallable. c) You find out that kmod are by design neither "upgrade", nor "coinstallable" class of packages. rpm/yum only know these two kind of packages. So now
c1) yum installs only kernel modules for the latest module version and the latest kernel. No newer module version is installed for older kernels even if they are available in the repo. That's because yum only coinstalls *the* newest which is a merged evr scheme is moduleversion/kernelversion. yum cannot guess the two dimensional background of the problem since it only sees one common evr.
c2) yum coinstalls kernel modules for the same kernels bailing out with file conflicts
d) no problem, we have workarounds for workarounds for workarounds [...] Why not undo the "damage" that bad yum inflicted on us for being rpm compatible. Let's detect those coinstalls-that-should-be-none and start removing package in the plugin.
Oops still not addressing the bug with yum + plugin not seeing kmods for previous kernels anymore at all!
Where would we be if we wouldn't start adding more workarounds, so let's take a look into the crystal ball
e) Jack persuades Seth to change the "kernel-module" yum-core behaviour from "kernel{,-flavour}" behaviour. The latter really wants yum to only see the latest version and coinstall it, but for the former we want yum to see them all and coinstall newer kernel modules for old kernels, too, e.g. trying to fix c1)
f) Now suddenly yum sees too much, it also sees kernel modules that have a newer one installed (which may happen even today see [1]), so we need to remove these from the ongoing transaction
g) It turned out that only some kernel modules are trivial enough to be removed on the fly in the transaction set. Many kernel modules have package dependencies that pull in or push out other packages. An old kernel module for instance "wrongly" selected for updating and later discarded by the plugin had pulled in incompatible firmware or it's older userland component.
Now how to detect which package was pulled in or pushed out by the unwanted packages in the transaction set? Let's think of a hack and find a workaroung later, the alphabet is long enough.
Hm, the alternative scheme only needed 99 lines of python for full unbroken yum support and no further yum-core manipulation?
Hm, ...
Hm, ...
On Mon, 2006-08-14 at 20:06 +0200, Thorsten Leemhuis wrote:
== 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.
I don't see what's the problem here: Old module packages get removed when the kernels they depend on (through kabi-provides or otherwise) get removed, either manually or by installonlyn-plugin.
- Panu -
On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote:
/lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
We already discussed that last week. You are moving the versioning problem of the modules away from rpm to module-init-tools.
You need to encode evr into the path and then teach depmod or any helper application to order according to rpm's evr scheme.
It's not an improvement, it's outsourcing a packaging/versioning problem to the wrong domain.
And allow me to remark that for someone clinging to the current scheme because of stability issues two hours ago, suggesting a radical new scheme as a way out is a contradiction, even if the new scheme would really solve something.
On Tue, 2006-08-15 at 01:57 +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote:
/lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
We already discussed that last week. You are moving the versioning problem of the modules away from rpm to module-init-tools.
Yes and no. He's moving it to /sbin/weak-modules which seems like a logical place. weak-modules has to understand how to place kernel modules (or links to them) into the tree for depmod and friends to find them. Right now it does this for kabi. It's not a big conceptual stretch to think that it could do this for kmod as well.
You need to encode evr into the path and then teach depmod or any helper application to order according to rpm's evr scheme.
Not necessarily. The helper application has to support a versioning scheme. We can make the ondisk directory layout match the helper's versioning scheme independent of the rpm evr. Certain versioning schemes on the part of the helper would be easier for us to work with, of course :-)
It's not an improvement, it's outsourcing a packaging/versioning problem to the wrong domain.
module-init-tools has to start supporting some sort of versioning scheme in order to support kabi. I'd argue that even without kabi, the tools should support a defined order in which they will choose what kernel modules to load. Leaving it undefined is a drawback for more than package managers.
Axel, do you see any reason Thorsten's proposal wouldn't work?
-Toshio
On Mon, Aug 14, 2006 at 05:33:14PM -0700, Toshio Kuratomi wrote:
On Tue, 2006-08-15 at 01:57 +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote:
/lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
We already discussed that last week. You are moving the versioning problem of the modules away from rpm to module-init-tools.
Yes and no. He's moving it to /sbin/weak-modules which seems like a logical place. weak-modules has to understand how to place kernel modules (or links to them) into the tree for depmod and friends to find them. Right now it does this for kabi. It's not a big conceptual stretch to think that it could do this for kmod as well.
You need to encode evr into the path and then teach depmod or any helper application to order according to rpm's evr scheme.
Not necessarily. The helper application has to support a versioning scheme. We can make the ondisk directory layout match the helper's versioning scheme independent of the rpm evr. Certain versioning schemes on the part of the helper would be easier for us to work with, of course :-)
Then what use would the evr be at all? yum is taught to ignore it and module-init-tools will ignore it, too. So if I issue a new release of the module it get's either coinstalled, or if there really is no 1-1 mapping it may even start overwrite the previous module.
It's not an improvement, it's outsourcing a packaging/versioning problem to the wrong domain.
module-init-tools has to start supporting some sort of versioning scheme in order to support kabi. I'd argue that even without kabi, the tools should support a defined order in which they will choose what kernel modules to load. Leaving it undefined is a drawback for more than package managers.
Axel, do you see any reason Thorsten's proposal wouldn't work?
Inability to replace a broken module? Ignoring evrs on modules? E.g. I can never go back to a previous version if 3w-9xxx turns out to be broken? Solving a problem by moving it to another domain?
kabi makes no sense for Fedora. It is soemthing for people wishing there existed a kernel abi like ISV/IHVs with mostly closed source content. Upstream kernel development has clearly stated that even due to political reasons there will not be a kernel api, it's documented in every kernel source and on every Fedora system in kernel-docs.
Vendors that will keep their kernels stable, e.g. only apply security bugfixes, can say that their have some kind of kernel abi and even give it a vendor-specfic name/value. Like RHEL4 was exporting kabi = 4.0 or similar. This makes only sense for RHEL and SLES, Fedora's kabi changes with every kernel release. Even RHEL5 will change it's "kabi" with every quaterly release, just like RHEL4U4 shows us. There is no other way to support new drivers and introducing kernel abi *metrics* is not introducing a kernel api/abi, which only the kernel developers could introduce, which they deliberately won't.
So kabi is of use only to ISV/IHVs with potentially closed source (or at least not commited upstream) of RHEL kernels within a quater of a year. For Fedora it's only an obstruction, and kernel modules falling under this category would not even make it into Fedora.
Don't get me wrong, I'n neither arguing against RHEL, ISVs, closed source or anything, I'm just showing what the use is for to show that we can't expect much.
What you can expect is indeed some limited recycling of kernel modules of previous kernel/kernel module installations especially on RHEL. But that's an orthogonal project to packaging them. weak-updates should check wherever kernel modules of the kernel package and the external kernel modules is placed and see whether the module is reusable.
I've added some bits of kabi discussion to the wiki:
http://fedoraproject.org/wiki/AxelThimm/kmdls
On Tue, Aug 15, 2006 at 02:53:03AM +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 05:33:14PM -0700, Toshio Kuratomi wrote:
On Tue, 2006-08-15 at 01:57 +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote:
/lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
We already discussed that last week. You are moving the versioning problem of the modules away from rpm to module-init-tools.
Yes and no. He's moving it to /sbin/weak-modules which seems like a logical place. weak-modules has to understand how to place kernel modules (or links to them) into the tree for depmod and friends to find them. Right now it does this for kabi. It's not a big conceptual stretch to think that it could do this for kmod as well.
You need to encode evr into the path and then teach depmod or any helper application to order according to rpm's evr scheme.
Not necessarily. The helper application has to support a versioning scheme. We can make the ondisk directory layout match the helper's versioning scheme independent of the rpm evr. Certain versioning schemes on the part of the helper would be easier for us to work with, of course :-)
Then what use would the evr be at all? yum is taught to ignore it and module-init-tools will ignore it, too. So if I issue a new release of the module it get's either coinstalled, or if there really is no 1-1 mapping it may even start overwrite the previous module.
It's not an improvement, it's outsourcing a packaging/versioning problem to the wrong domain.
module-init-tools has to start supporting some sort of versioning scheme in order to support kabi. I'd argue that even without kabi, the tools should support a defined order in which they will choose what kernel modules to load. Leaving it undefined is a drawback for more than package managers.
Axel, do you see any reason Thorsten's proposal wouldn't work?
Inability to replace a broken module? Ignoring evrs on modules? E.g. I can never go back to a previous version if 3w-9xxx turns out to be broken? Solving a problem by moving it to another domain?
kabi makes no sense for Fedora. It is soemthing for people wishing there existed a kernel abi like ISV/IHVs with mostly closed source content. Upstream kernel development has clearly stated that even due to political reasons there will not be a kernel api, it's documented in every kernel source and on every Fedora system in kernel-docs.
Vendors that will keep their kernels stable, e.g. only apply security bugfixes, can say that their have some kind of kernel abi and even give it a vendor-specfic name/value. Like RHEL4 was exporting kabi = 4.0 or similar. This makes only sense for RHEL and SLES, Fedora's kabi changes with every kernel release. Even RHEL5 will change it's "kabi" with every quaterly release, just like RHEL4U4 shows us. There is no other way to support new drivers and introducing kernel abi *metrics* is not introducing a kernel api/abi, which only the kernel developers could introduce, which they deliberately won't.
So kabi is of use only to ISV/IHVs with potentially closed source (or at least not commited upstream) of RHEL kernels within a quater of a year. For Fedora it's only an obstruction, and kernel modules falling under this category would not even make it into Fedora.
Don't get me wrong, I'n neither arguing against RHEL, ISVs, closed source or anything, I'm just showing what the use is for to show that we can't expect much.
What you can expect is indeed some limited recycling of kernel modules of previous kernel/kernel module installations especially on RHEL. But that's an orthogonal project to packaging them. weak-updates should check wherever kernel modules of the kernel package and the external kernel modules is placed and see whether the module is reusable.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Jack Neely -
Jesse Keating -
Panu Matilainen -
Thorsten Leemhuis -
Toshio Kuratomi