Hi,
I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme.
a) kernel module scheme needs uname-r-in-name
b) kernel module scheme needs one-specfile approach (for both usreland and kernel modules)
c) kernel module scheme needs to be kernel agnostic (both version *and* flavour)
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
e) Adoption of kmdl interface scheme as used at ATrpms and outlined on http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive vote on a-d)
f) Assignment to kmdl-task force to integrate kmdl support into the buildsystems used by Fedora (myself volunteering). Requires a positive vote on a-e)
g) Allow kmdl package submissions to Fedora Core/Extras. Requires a positive vote on a-f)
Without voting, but dependent on vote results: Assist in GFS kmdl packaging (altready done at FC4 times, needs to resurface).
On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote:
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
Rather than vote on these issues as Axel suggests (which we can certainly do), I think that perhaps we should look at a different approach:
Just throwing it out here, but I don't really see consensus on this issue. People either like kmod or kmdl, and I think there are definite pros/cons to each approach. My instinct is that if we vote on Axel's items, they will not pass. And I don't think it is because the kmdl standard is broken or outright wrong, I think much of it is due to the fact that so much pain and effort went into making the kmod standard (which works for the majority of cases) that people are honestly unwilling to start over.
So, here's the heretical proposition:
How about we permit either kmod OR kmdl as an acceptable standard? E.g. Document both, and let the packager choose?
I see kernel module packaging as one of the last barriers to bringing in contributions from open source, unencumbered 3rd party repo packages. Given the near religious nature of this debate, maybe a little flexibility (not infinite flexibility) is merited here for the greater good?
Thoughts?
~spot
On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway wrote:
On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote:
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
Rather than vote on these issues as Axel suggests (which we can certainly do), I think that perhaps we should look at a different approach:
Just throwing it out here, but I don't really see consensus on this issue. People either like kmod or kmdl, and I think there are definite pros/cons to each approach. My instinct is that if we vote on Axel's items, they will not pass. And I don't think it is because the kmdl standard is broken or outright wrong, I think much of it is due to the fact that so much pain and effort went into making the kmod standard (which works for the majority of cases) that people are honestly unwilling to start over.
So, here's the heretical proposition:
How about we permit either kmod OR kmdl as an acceptable standard? E.g. Document both, and let the packager choose?
I see kernel module packaging as one of the last barriers to bringing in contributions from open source, unencumbered 3rd party repo packages. Given the near religious nature of this debate, maybe a little flexibility (not infinite flexibility) is merited here for the greater good?
umm - then we'll need both plugins and it will be near impossible to make sure they play nicely.
moreover - if a package switches owners and one likes kmod while the previous one likes kmdl then we're kinda, umm, screwed.
the packaging committee should make a choice, go with and then it is done.
that's the whole point of the committee.
-sv
seth vidal schrieb:
On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway wrote:
On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote:
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
Rather than vote on these issues as Axel suggests (which we can certainly do), I think that perhaps we should look at a different approach:
Just throwing it out here, but I don't really see consensus on this issue. People either like kmod or kmdl, and I think there are definite pros/cons to each approach. My instinct is that if we vote on Axel's items, they will not pass. And I don't think it is because the kmdl standard is broken or outright wrong, I think much of it is due to the fact that so much pain and effort went into making the kmod standard (which works for the majority of cases) that people are honestly unwilling to start over.
So, here's the heretical proposition:
How about we permit either kmod OR kmdl as an acceptable standard? E.g. Document both, and let the packager choose?
I see kernel module packaging as one of the last barriers to bringing in contributions from open source, unencumbered 3rd party repo packages. Given the near religious nature of this debate, maybe a little flexibility (not infinite flexibility) is merited here for the greater good?
umm - then we'll need both plugins and it will be near impossible to make sure they play nicely.
moreover - if a package switches owners and one likes kmod while the previous one likes kmdl then we're kinda, umm, screwed.
And we need proper support for both standards in plague.
And having two standard is confusing for the users, too.
the packaging committee should make a choice, go with and then it is done.
that's the whole point of the committee.
+1
Cu thl
On Fri, 2006-08-11 at 16:53 -0400, seth vidal wrote:
On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway wrote:
On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote:
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
Rather than vote on these issues as Axel suggests (which we can certainly do), I think that perhaps we should look at a different approach:
Just throwing it out here, but I don't really see consensus on this issue. People either like kmod or kmdl, and I think there are definite pros/cons to each approach. My instinct is that if we vote on Axel's items, they will not pass. And I don't think it is because the kmdl standard is broken or outright wrong, I think much of it is due to the fact that so much pain and effort went into making the kmod standard (which works for the majority of cases) that people are honestly unwilling to start over.
So, here's the heretical proposition:
How about we permit either kmod OR kmdl as an acceptable standard? E.g. Document both, and let the packager choose?
I see kernel module packaging as one of the last barriers to bringing in contributions from open source, unencumbered 3rd party repo packages. Given the near religious nature of this debate, maybe a little flexibility (not infinite flexibility) is merited here for the greater good?
umm - then we'll need both plugins and it will be near impossible to make sure they play nicely.
moreover - if a package switches owners and one likes kmod while the previous one likes kmdl then we're kinda, umm, screwed.
+1
Having both standards mix and match is by far the worst of both worlds IMNSHO.
the packaging committee should make a choice, go with and then it is done.
that's the whole point of the committee.
Another +1
Both choices have their weak and strong points. If it's impossible to decide based on technical merits alone... flip a coin or something, really.
- Panu -
On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
Both choices have their weak and strong points. If it's impossible to decide based on technical merits alone... flip a coin or something, really.
Or continue to use the current one that is being used by current packages in Extras, and in RHEL.
On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
Both choices have their weak and strong points. If it's impossible to decide based on technical merits alone... flip a coin or something, really.
Or continue to use the current one that is being used by current packages in Extras, and in RHEL.
and which cannot be used for manual rpm installations, breaks all depsolvers, endangers your running setup or the total upgradablity of the system and the ugly workarounds trying to fix this turn out to introduce more bugs that they fix making the depsolver support a maintenance nightmare.
Workaround 1: assume rpm -i is in order, add "kernel-modules" coinstall support in yum proper Workaround 2: find out that the coinstall support is not enough, additionally write a plugin Workaround 3: find out that rpm -i isn't the proper mode, try to fix the plugin for yum, despair on rpm Workaround 4: find out that the plugin for yum is still incomplete and possibly cannot be ever fixed. Workaround 5: Impose restrictions on kernel modules and their usage so that unfixable bugs are not triggered [*].
In contrast to well behaved rpm, yum and all other from the very start and a trivial plugin to make yum usage more comfortable not even needeing special "kernel-modules" support?
FYI there is exatly 1 (one) package in extras using the kernel module scheme and RHEL is just being taught kmods (GFS) - it's not too late to avoid RHEL5 ship with such a broken scheme unless we decide to discuss this forever.
[*] Like - never use rpm cli - never have dependencies of kernel module packages on other packages (breaks GFS/cman/dlm/...)
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
Both choices have their weak and strong points. If it's impossible to decide based on technical merits alone... flip a coin or something, really.
Or continue to use the current one that is being used by current packages in Extras, and in RHEL.
and which cannot be used for manual rpm installations, breaks all depsolvers, endangers your running setup or the total upgradablity of the system and the ugly workarounds trying to fix this turn out to introduce more bugs that they fix making the depsolver support a maintenance nightmare.
To be fair, the only change to kmod that would be necessary to remove all of this "it won't work for manual rpm installations" is the addition of kver in the Name field.
So far, the only technical reason that I've heard mentioned here against adding kver to Name is that it would make debuginfo more complicated for kmod packages (and I believe that someone posted a workaround method). In fact, I suspect that kmodtool could even include the necessary magic.
~spot
Tom 'spot' Callaway schrieb:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
So far, the only technical reason that I've heard mentioned here against adding kver to Name is that it would make debuginfo more complicated for kmod packages (and I believe that someone posted a workaround method).
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
In fact, I suspect that kmodtool could even include the necessary magic.
Sure, that would be possible. But we'll hit other problems after this major scheme change. We probably hit some in the old livna days, but I forget most of them already (sorry -- maybe I can skip though bugzilla to fresh up my mind). But I think sticking to the current scheme and solving the "install-conflicts" problem together with the kabi stuff would be the better idea.
CU thl
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
So far, the only technical reason that I've heard mentioned here against adding kver to Name is that it would make debuginfo more complicated for kmod packages (and I believe that someone posted a workaround method).
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
I'm not sure I see how this automatically works in the current kmod scheme (or alternately, how it doesn't work in the kmod+kver scheme).
In fact, I suspect that kmodtool could even include the necessary magic.
Sure, that would be possible. But we'll hit other problems after this major scheme change. We probably hit some in the old livna days, but I forget most of them already (sorry -- maybe I can skip though bugzilla to fresh up my mind). But I think sticking to the current scheme and solving the "install-conflicts" problem together with the kabi stuff would be the better idea.
Again, I tend to defer to people who know more about packaging kernel modules than I do.
~spot
Tom 'spot' Callaway schrieb:
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
So far, the only technical reason that I've heard mentioned here against adding kver to Name is that it would make debuginfo more complicated for kmod packages (and I believe that someone posted a workaround method).
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
I'm not sure I see how this automatically works in the current kmod scheme
Example (without a special plugin): --- 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 ---
(or alternately, how it doesn't work in the kmod+kver scheme).
Example (without a special plugin): --- Installed are: kernel-2.6.17-1.2157_FC5 kmod-foo-2.6.17-1.2157_FC5-1.2
kernel-2.6.17-1.2171_FC5 and kmod-foo-2.6.17-1.2171_FC5-1.2 are pushed to the repo
Yum will install: kernel-2.6.17-1.2171_FC5
kmod-foo-2.6.17-1.2171_FC5-1.2 won't get installed because it a new package for yum whit a different name ---
In fact, I suspect that kmodtool could even include the necessary magic.
Sure, that would be possible. But we'll hit other problems after this major scheme change. We probably hit some in the old livna days, but I forget most of them already (sorry -- maybe I can skip though bugzilla to fresh up my mind). But I think sticking to the current scheme and solving the "install-conflicts" problem together with the kabi stuff would be the better idea.
Again, I tend to defer to people who know more about packaging kernel modules than I do.
I'll outline my idea in a more detailed mail I'll start preparing now.
CU thl
On Mon, Aug 14, 2006 at 06:02:51PM +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
So far, the only technical reason that I've heard mentioned here against adding kver to Name is that it would make debuginfo more complicated for kmod packages (and I believe that someone posted a workaround method).
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
I'm not sure I see how this automatically works in the current kmod scheme
Example (without a special plugin):
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
(or alternately, how it doesn't work in the kmod+kver scheme).
Example (without a special plugin):
Installed are: kernel-2.6.17-1.2157_FC5 kmod-foo-2.6.17-1.2157_FC5-1.2
kernel-2.6.17-1.2171_FC5 and kmod-foo-2.6.17-1.2171_FC5-1.2 are pushed to the repo
Yum will install: kernel-2.6.17-1.2171_FC5
kmod-foo-2.6.17-1.2171_FC5-1.2 won't get installed because it a new package for yum whit a different name
In fact, I suspect that kmodtool could even include the necessary magic.
Sure, that would be possible. But we'll hit other problems after this major scheme change. We probably hit some in the old livna days, but I forget most of them already (sorry -- maybe I can skip though bugzilla to fresh up my mind). But I think sticking to the current scheme and solving the "install-conflicts" problem together with the kabi stuff would be the better idea.
Again, I tend to defer to people who know more about packaging kernel modules than I do.
I'll outline my idea in a more detailed mail I'll start preparing now.
CU thl
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
Thorsten,
+1
This lack of functionality is a complete show stopper. I've been using a very similar method to the kmod example above for 6+ years. Its not been Pain Free(tm) but I have to have an automated system of deploying updates and kernel modules. Its just not an option or something that I will gladly re-invent.
Jack
On Mon, Aug 14, 2006 at 06:02:51PM +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
So far, the only technical reason that I've heard mentioned here against adding kver to Name is that it would make debuginfo more complicated for kmod packages (and I believe that someone posted a workaround method).
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
I'm not sure I see how this automatically works in the current kmod scheme
Example (without a special plugin):
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
Example: kmod-foo-1.3.2.6.17-1.2171_FC5 is pushed to the repo
- yum update will bail out of file conflicts - OR will happily coinstall if the paths are disambiguated (worse)
Example (yum w/o special plugin and special kernel-modules handling in core):
- kmod-foo-1.2.2.6.17-1.2157_FC5 get nuked. Oops ...
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
up2date/rhel5 isn't an issue.
rhel5 is basing off of yum - like fedora is. So the plugins available here can be used there, too.
-sv
seth vidal schrieb:
rhel5 is basing off of yum - like fedora is. So the plugins available here can be used there, too.
Ohh, didn't know that. Interesting.
BTW, why isn't jcmasters (the men behind the kabi stuff for RHEL) participating in this discussion? Is he on holiday (i poked hime once via e-mail but I got no response)? I think it's important to get him involved in this discussion.
CU thl
On Mon, Aug 14, 2006 at 11:02:35AM -0400, seth vidal wrote:
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
Just FYI the kernel api/abi between RHEL4U3 and RHEL4U4 broke again at least in the wireless extensions submodule. I don't think that this will be different with RHEL5U<N> --> U<N+1> updates.
up2date/rhel5 isn't an issue.
rhel5 is basing off of yum - like fedora is. So the plugins available here can be used there, too.
That's good news. Does that mean that yum has rhn support?
I started shipping the kmdl plugin to ATrpms' users, but would prefer it to get into yum-utils as a subpackage. If approved should I send you a patch for CVS and one for the specfile?
On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote:
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
o the yum-plugin for kmods is broken and possibly cannot be rectified, see mail to Jack
o "out of the box" the current scheme is severely broken. In yum you get file conflicts, in rpm total breakage and in smart/apt you get your running kernel modules nuked.
You make it sound like the kmdl scheme needs special handling, while it's the other way round. The kmdl scheme does never jeopardize your existing install and this inherits to all depsolvers and rpm. While the kmod scheme violates basic rpm ordering rules and tried to rectify with in-depsolver special handling *and* plugins and has already been shown to be broken by design.
On Mon, Aug 14, 2006 at 05:33:10PM +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote:
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
o the yum-plugin for kmods is broken and possibly cannot be rectified, see mail to Jack
Ah, breakage. Tisk, tisk. Solve this one:
Installed are: kernel-2.6.17-1.2157_FC5 kmod-foo-2.6.17-1.2157_FC5-1.2 foo-1.2-1_FC5
where kmod-foo-1.2.2.6.17-1.2157_FC5 requires foo = 1.2
Yum has: kernel-2.6.17-1.2171_FC5 kmod-foo-2.6.17-1.2171_FC5-1.3 foo-1.3_FC5
And kmod-foo-2.6.17-1.2171_FC5-1.2 requires foo = 1.3.
So what happens here?
# yum update
We reboot into our new kernel and 10 minutes later we see that foo is totally broken because there's not a kernel module for it.
# yum install kmod-foo-2.6.17-1.2171_FC5
Yum pulls in foo-1.3 to meet the requirements. Now we experiance pain as foo-1.2 and foo-1.3 are userland packages and cannot be co-installed.
This affects both schemes. Is this a technical problem that can be fixed?
o "out of the box" the current scheme is severely broken. In yum you get file conflicts, in rpm total breakage and in smart/apt you get your running kernel modules nuked.
I did this with Yup (of all horrid, gross, gangly things) 6 years ago with a bit of documentation/policy.
You make it sound like the kmdl scheme needs special handling, while it's the other way round. The kmdl scheme does never jeopardize your existing install and this inherits to all depsolvers and rpm. While the kmod scheme violates basic rpm ordering rules and tried to rectify with in-depsolver special handling *and* plugins and has already been shown to be broken by design. -- Axel.Thimm at ATrpms.net
The kmdl scheme *does* require depsolver modifications to work. I must be able to push out updated kernel modules to my clients in an automated fashion.
Jack
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Mon, Aug 14, 2006 at 03:49:50PM -0400, Jack Neely wrote:
On Mon, Aug 14, 2006 at 05:33:10PM +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote:
You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
o the yum-plugin for kmods is broken and possibly cannot be rectified, see mail to Jack
Ah, breakage. Tisk, tisk. Solve this one:
Altready solved since long in ATrpms' everyday life.
Installed are: kernel-2.6.17-1.2157_FC5 kmod-foo-2.6.17-1.2157_FC5-1.2 foo-1.2-1_FC5
where kmod-foo-1.2.2.6.17-1.2157_FC5 requires foo = 1.2
Yum has: kernel-2.6.17-1.2171_FC5 kmod-foo-2.6.17-1.2171_FC5-1.3 foo-1.3_FC5
And kmod-foo-2.6.17-1.2171_FC5-1.2 requires foo = 1.3.
You probably have a typo here, the first item is supposed to end with 1.3
So what happens here?
You are trying to do both a kernel upgrade and module version upgrade. You only get into that situation because you skipped the intermediate step (which can happen simultaneously): You don't only build mod-foo-2.6.17-1.2171_FC5-1.3, you also build kmod-foo-2.6.17-1.2157_FC5-1.3.
# yum update
Updates everything to 1.3
We reboot into our new kernel and 10 minutes later we see that foo is totally broken because there's not a kernel module for it.
Only if you messed up by simultaneous upgrading kernel and module version w/o offering interim versions.
# yum install kmod-foo-2.6.17-1.2171_FC5
Yum pulls in foo-1.3 to meet the requirements. Now we experiance pain as foo-1.2 and foo-1.3 are userland packages and cannot be co-installed.
Note that kernel modules have two version (evrs to be exact):
o the kernel version: follows the kernel's example and allows going back and forth
o the module version: follows a conventional package's upgrading
If the new kernel is broken you can reboot to the previous one. If the module itself is bogus you need to downgrade as you do with conventional packages.
This affects both schemes. Is this a technical problem that can be fixed?
Not a problem with kmdls.
You make it sound like the kmdl scheme needs special handling, while it's the other way round. The kmdl scheme does never jeopardize your existing install and this inherits to all depsolvers and rpm. While the kmod scheme violates basic rpm ordering rules and tried to rectify with in-depsolver special handling *and* plugins and has already been shown to be broken by design.
The kmdl scheme *does* require depsolver modifications to work. I must be able to push out updated kernel modules to my clients in an automated fashion.
Once again arguing in circles, but repetions works:
o kmod scheme: requires workaround in yum core and requires a yum plugin to not start nuking running kernel modules or file conflicting or partial overwrites
o kmdl scheme: requires trivial yum plugin to have new kernel installs automatically coinstall kmdls
Note both say "requires", but the first is requires as in "requires, otherwise havoc is programmed", while the latter is "requires for added comfort"
Yes, let's allow kmdls to become more comfortable, but don't compare neccessity of (trying to) unbreak things with adding automatism.
On Mon, Aug 14, 2006 at 08:44:08AM -0500, Tom 'spot' Callaway wrote:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
Both choices have their weak and strong points. If it's impossible to decide based on technical merits alone... flip a coin or something, really.
Or continue to use the current one that is being used by current packages in Extras, and in RHEL.
and which cannot be used for manual rpm installations, breaks all depsolvers, endangers your running setup or the total upgradablity of the system and the ugly workarounds trying to fix this turn out to introduce more bugs that they fix making the depsolver support a maintenance nightmare.
To be fair, the only change to kmod that would be necessary to remove all of this "it won't work for manual rpm installations" is the addition of kver in the Name field.
It sounds like it's a minor details, but it's a major design block. If you also agree to one specfile handling for both userland/kernelland you end up at kmdl's versioning with a different name.
And since one does throw out the biggest design elements, why not bring in all the other good stuff that kmdls bring with them? Nobody objected to the rest of the benfits only the uname-r-in-name stuff is being discussed.
On Mon, Aug 14, 2006 at 08:44:08AM -0500, Tom 'spot' Callaway wrote:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
Both choices have their weak and strong points. If it's impossible to decide based on technical merits alone... flip a coin or something, really.
Or continue to use the current one that is being used by current packages in Extras, and in RHEL.
and which cannot be used for manual rpm installations, breaks all depsolvers, endangers your running setup or the total upgradablity of the system and the ugly workarounds trying to fix this turn out to introduce more bugs that they fix making the depsolver support a maintenance nightmare.
To be fair, the only change to kmod that would be necessary to remove all of this "it won't work for manual rpm installations" is the addition of kver in the Name field.
So far, the only technical reason that I've heard mentioned here against adding kver to Name is that it would make debuginfo more complicated for kmod packages (and I believe that someone posted a workaround method). In fact, I suspect that kmodtool could even include the necessary magic.
~spot
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
No one has offered an explanation or yum plugin to handle scalability. A new kernel is released. How do I push out a new kernel module to all my machines? This scheme only appears to scale to 1 person with root on his home machine. I need to power an entire university.
Because kmdl modules do not follow the kernel that adds yet another reason why upgrading to the latest kernel is painful and to be avoided. We all know where this slippery slope goes.
Jack
On Mon, Aug 14, 2006 at 03:27:44PM -0400, Jack Neely wrote:
No one has offered an explanation or yum plugin to handle scalability.
What about the plugin I submitted to this very list?
A new kernel is released. How do I push out a new kernel module to all my machines? This scheme only appears to scale to 1 person with root on his home machine. I need to power an entire university.
yum update with the kmdl plugin is enough. You still need to be root on all the machines though ;)
Because kmdl modules do not follow the kernel that adds yet another reason why upgrading to the latest kernel is painful and to be avoided. We all know where this slippery slope goes.
Of course they follow the kernel, that's what the plugin is for.
Just to give the good example. Please do your voting and let's see where we stand. My batteries are running out, repeating the same arguments again and again isn't fun. So let's either do it or drown it.
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
Hi,
I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme.
a) kernel module scheme needs uname-r-in-name
+1
b) kernel module scheme needs one-specfile approach (for both usreland and kernel modules)
+1
c) kernel module scheme needs to be kernel agnostic (both version *and* flavour)
+1
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
+1
e) Adoption of kmdl interface scheme as used at ATrpms and outlined on http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive vote on a-d)
+1
f) Assignment to kmdl-task force to integrate kmdl support into the buildsystems used by Fedora (myself volunteering). Requires a positive vote on a-e)
+1
g) Allow kmdl package submissions to Fedora Core/Extras. Requires a positive vote on a-f)
+1
Without voting, but dependent on vote results: Assist in GFS kmdl packaging (altready done at FC4 times, needs to resurface).
Axel Thimm wrote:
Just to give the good example. Please do your voting and let's see where we stand. My batteries are running out, repeating the same arguments again and again isn't fun. So let's either do it or drown it.
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
Hi,
I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme.
I'd have to say that change here is warranted and Axel's proposal(s) make the most sense to me: afaict, a-g all +1
-- Rex
Rex Dieter schrieb:
Axel Thimm wrote:
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme.
I'd have to say that change here is warranted and Axel's proposal(s) make the most sense to me: afaict, a-g all +1
Rex, could you please describe why you think this scheme it better? I'm fine with changing details (I'm still unsure if the uname -r in NAME is a good thing or bad), but why throw everything over board that was developed, discussed and agreed on by the old FESCo? Are there any problems you're seeing with the current scheme?
CU thl
Thorsten Leemhuis wrote:
Rex Dieter schrieb:
Axel Thimm wrote:
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme.
I'd have to say that change here is warranted and Axel's proposal(s) make the most sense to me: afaict, a-g all +1
Rex, could you please describe why you think this scheme it better?
I *could* just parrot Axel's previous empteen mails on the subject... (: In short, I found myself agreeing with his analysis of the shortcomings of the current kmod scheme and advantages of his kmdl proposal.
-- Rex
Axel Thimm schrieb:
a) kernel module scheme needs uname-r-in-name
+/-0 currently if we only work for Fedora here.
-1 currently if we want the same stuff in RHEL and Fedora -- the "uname -r" is not that important with the kabi stuff and the problem should be fixed properly.
Note the word "currently".
b) kernel module scheme needs one-specfile approach (for both usreland and kernel modules)
-1 ; Reasons:
- changes only in the kmod will require that the userland packages gets rebuild, too. That unnecessary. Yes, it can be prevented manually. But we would have to make sure that SRPMs for the old userland packages stay in the repo; and we would need special handling in the buildsys -> can of worms.
- people during the last kmod development didn't like having spec files with a lot of -- %if userland do stuff to build userland #endif %if module do stuff to build kmod #endif
- Because the name of the SRPM doesn't change when you rebuild stuff for a newly released kernel the name of the debuginfo packages does also not change. So with a one-specfile approach we'd have to
-- created manually; we tried that during the development of the kmod standard. We didn't like it
or
-- that the release in increased everytime so the new debuginfo packages gets a new name -- creates the SRPMS problem described above
c) kernel module scheme needs to be kernel agnostic (both version *and* flavour)
+1 -- They are agnostic already. The current hardwiring in the spec file is only a temporary solution until we have proper support in the buildsys. Yes, there is one place in "kmodtool" where the flavours are hardcoded for users that rebuild kmods manually to prevent that they do something wrong.
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
-1 -- we took about half a year to develop the current standard for FE. I'm not going to switch to something where besides Axel no one of the people around has practical experiences
- in a hurry
- without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
- after test2
- shortly before RHEL beta 1 (or is it out already?)
I'd even tend to say: We shouldn't change what was discussed below "a)" (see above) at this point. To risky IMHO.
e) [...] Requires a positive vote on a-d) [...]
I had to many -1 up to here, so I'm stopping now ;-)
CU thl
On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote:
+/-0 currently if we only work for Fedora here.
0 is equal to -1 in fedora-packaging
-1 currently if we want the same stuff in RHEL and Fedora -- the "uname -r" is not that important with the kabi stuff and the problem should be fixed properly.
kabi argumentation was shown to not lead anywhere, not even with RHEL.
- changes only in the kmod will require that the userland packages gets
rebuild, too.
Changes to glibc-devel will require rebuilding glibc, too. Should we decompose each package into that many src.rpm as it has suppackages???
- Because the name of the SRPM doesn't change when you rebuild stuff for
a newly released kernel the name of the debuginfo packages does also not change.
That was addressed by Ville on this list and the full sane and elegant solution already presented. So the rest of the argument is bogus.
c) kernel module scheme needs to be kernel agnostic (both version *and* flavour)
+1 -- They are agnostic already. The current hardwiring in the spec file is only a temporary solution [...]
It's hardcoded in the guidelines.
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
-1 -- we took about half a year to develop the current standard for FE. I'm not going to switch to something where besides Axel no one of the people around has practical experiences
in a hurry
without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
after test2
shortly before RHEL beta 1 (or is it out already?)
I'd even tend to say: We shouldn't change what was discussed below "a)" (see above) at this point. To risky IMHO.
Are you are trying to subvert the voting by raising the bar too high? The current scheme was proven to be broken, there is nothing more that can be broken, the kmdl scheme was presented and is in practice at ATrpms for *years*. So you have both theoretical and practical proof on the benefits.
And please consider that you are endorsing a standard for RHEL that is known to break the yum kmod plugin when it comes to GFS/cman dependencies, which is the only place where FC or RHEL really use kernel modules.
Should Fedora's heritage to RHEL be a completely broken cluster/gfs setup or should we wait until RHEL's QA addresses upgradability, and dumps the current scheme then? Or worse, have the customers find out?
Axel Thimm schrieb:
On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote:
+/-0 currently if we only work for Fedora here.
0 is equal to -1 in fedora-packaging
Sorry, "0" meant undecided for me.
-1 currently if we want the same stuff in RHEL and Fedora -- the "uname -r" is not that important with the kabi stuff and the problem should be fixed properly.
kabi argumentation was shown to not lead anywhere, not even with RHEL.
"--verbose" please, seems I missed something here.
I prefer to have the same stuff in RHEL and Fedora -- even if it of small use in Fedora.
- changes only in the kmod will require that the userland packages gets
rebuild, too.
Changes to glibc-devel will require rebuilding glibc, too. Should we decompose each package into that many src.rpm as it has suppackages???
Well, kmod packages in my experience need some updates now and then (e.g. special patches for a new kernel version). I prefer to save our users the download of a new userland package in that case.
That by itself of course doesn't warrent the split. But together with the two other reasons I gave I think it's okay.
(Note, I didn't like the split in the beginning when we created the current kmod standard. I really like it now that I got used to it).
- Because the name of the SRPM doesn't change when you rebuild stuff for
a newly released kernel the name of the debuginfo packages does also not change.
That was addressed by Ville on this list and the full sane and elegant solution already presented. So the rest of the argument is bogus.
You mean https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html ? That stuff is what I meant with: --- [...] -- created manually; we tried that during the development of the kmod standard. We didn't like it [...] --- in my mail you replied to.
c) kernel module scheme needs to be kernel agnostic (both version *and* flavour)
+1 -- They are agnostic already. The current hardwiring in the spec file is only a temporary solution [...]
It's hardcoded in the guidelines.
Well, you would have to hardcode it also until the buildsys gains proper support for your scheme. The guidelines ever state that is an interim solution: # stuff to be implemented externally: [...] # hardcode for now: [...]
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
-1 -- we took about half a year to develop the current standard for FE. I'm not going to switch to something where besides Axel no one of the people around has practical experiences
in a hurry
without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
after test2
shortly before RHEL beta 1 (or is it out already?)
I'd even tend to say: We shouldn't change what was discussed below "a)" (see above) at this point. To risky IMHO.
Are you are trying to subvert the voting by raising the bar too high? The current scheme was proven to be broken
"in your opinion" is missing here. Or I lost track completely here. Yes, there is the problem described in https://www.redhat.com/archives/fedora-packaging/2006-August/msg00079.htmlis
But switching to a total different solution is not the only way to fix this. Further: I got not only one bug report due to this. I got many report due to problems when we had the "uname -r" in the name.
If I'm missing other real "problems" please enlight me. tia!
, there is nothing more that can be broken, the kmdl scheme was presented and is in practice at ATrpms for *years*. So you have both theoretical and practical proof on the benefits.
The kmod scheme works fine in lvn for FC5, too. That's not years. But we had years with problems with the other scheme that used to have "uname -r" in the name.
And please consider that you are endorsing a standard for RHEL
I do -- that's why I'm proposing a solution based on the current one that works on both FC and RHEL.
that is known to break the yum kmod plugin when it comes to GFS/cman dependencies, which is the only place where FC or RHEL really use kernel modules.
GFS2 is in the Fedoras main kernel package for some time now. See http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?view=... for details. I suspect that will be the case for RHEL, too.
CU thl
On Mon, Aug 14, 2006 at 07:41:40PM +0200, Thorsten Leemhuis wrote:
-1 currently if we want the same stuff in RHEL and Fedora -- the "uname -r" is not that important with the kabi stuff and the problem should be fixed properly.
kabi argumentation was shown to not lead anywhere, not even with RHEL.
"--verbose" please, seems I missed something here.
Then please check the archives it was after all an answer to a mail from you. Alternatively please outline what you suppose any kabi stuff will bring in other than a further delay?
I prefer to have the same stuff in RHEL and Fedora -- even if it of small use in Fedora.
I agree and ATrpms ships kmdls for RHEL3 and RHEL4 since years, too. Part of kmdl's design is so that RHEL3 is supported, too.
So RHEL is not an issue with kmdls, more an argument in favour of them.
- changes only in the kmod will require that the userland packages gets
rebuild, too.
Changes to glibc-devel will require rebuilding glibc, too. Should we decompose each package into that many src.rpm as it has suppackages???
Well, kmod packages in my experience need some updates now and then (e.g. special patches for a new kernel version). I prefer to save our users the download of a new userland package in that case.
That by itself of course doesn't warrent the split. But together with the two other reasons I gave I think it's okay.
Which were debunked, too. And please add the confusion of users when say nvidia does not work. File a bug against kmdo-nvidia or nvidia? Check changelogs of which package for what change?
- Because the name of the SRPM doesn't change when you rebuild stuff for
a newly released kernel the name of the debuginfo packages does also not change.
That was addressed by Ville on this list and the full sane and elegant solution already presented. So the rest of the argument is bogus.
You mean https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html ? That stuff is what I meant with:
[...] -- created manually; we tried that during the development of the kmod standard. We didn't like it [...]
in my mail you replied to.
What is manual about it? It works fully transparently in the background like the usual debuginfo stuff does. There are no manual actions required or manual entries in specfiles. You don't even need to patch up redhat-rpm-macros. It can't be more automatic ...
I'd even tend to say: We shouldn't change what was discussed below "a)" (see above) at this point. To risky IMHO.
Are you are trying to subvert the voting by raising the bar too high? The current scheme was proven to be broken
"in your opinion" is missing here. Or I lost track completely here.
Everything is in my opinion of course, even that 2+2=4. Still the current scheme factually remains broken whether it's my opinion or not.
But switching to a total different solution is not the only way to fix this.
I showed inductively that uname-r-in-name is a neccessity. The other way is to patch up rpm to use a new rpmvercmp. Not ever going to happen IMO. The way you seem to prefer is to live with broken rpm semantics and try to cover up with plugins that try to save the day for yum but abandon rpm broken and only cover our eyes with dirt that yum is working.
Further: I got not only one bug report due to this.
Lack of usage? Lack of updated packages? yum dependency calculation abort (wrongly) attributed to something else? User totally confused on the cause of havoc attributing it to his usage?
You know when and *that* it triggers inevitably. You don't need bug reports for something proven to be the case. I neither have seen any bug reports on rm -fr / being bad ...
And please consider that you are endorsing a standard for RHEL
I do -- that's why I'm proposing a solution based on the current one that works on both FC and RHEL.
that is known to break the yum kmod plugin when it comes to GFS/cman dependencies, which is the only place where FC or RHEL really use kernel modules.
GFS2 is in the Fedoras main kernel package for some time now. See http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?view=... for details. I suspect that will be the case for RHEL, too.
Who said GFS2? GFS is "GFS1" introduced in RHEL3 and supported in RHEL4 and RHEL5, it denotes an online format as contrasted to actual GFS versioning (like 6.0 and 6.1). GFS will continue to live outside the kernel package and is required to support every productive GFS setup out there. There are no GFS2 productive setups to date (because there is no enterprise supported solution for GFS2 yet released, RHEL5 possibly layered would be the first)
So it remains the current hertiage is a broken GFS setup for RHEL.
On Mon, Aug 14, 2006 at 06:56:15PM +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote:
+/-0 currently if we only work for Fedora here.
0 is equal to -1 in fedora-packaging
-1 currently if we want the same stuff in RHEL and Fedora -- the "uname -r" is not that important with the kabi stuff and the problem should be fixed properly.
kabi argumentation was shown to not lead anywhere, not even with RHEL.
- changes only in the kmod will require that the userland packages gets
rebuild, too.
Changes to glibc-devel will require rebuilding glibc, too. Should we decompose each package into that many src.rpm as it has suppackages???
- Because the name of the SRPM doesn't change when you rebuild stuff for
a newly released kernel the name of the debuginfo packages does also not change.
That was addressed by Ville on this list and the full sane and elegant solution already presented. So the rest of the argument is bogus.
c) kernel module scheme needs to be kernel agnostic (both version *and* flavour)
+1 -- They are agnostic already. The current hardwiring in the spec file is only a temporary solution [...]
It's hardcoded in the guidelines.
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
-1 -- we took about half a year to develop the current standard for FE. I'm not going to switch to something where besides Axel no one of the people around has practical experiences
in a hurry
without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
after test2
shortly before RHEL beta 1 (or is it out already?)
I'd even tend to say: We shouldn't change what was discussed below "a)" (see above) at this point. To risky IMHO.
Are you are trying to subvert the voting by raising the bar too high? The current scheme was proven to be broken, there is nothing more that can be broken, the kmdl scheme was presented and is in practice at ATrpms for *years*. So you have both theoretical and practical proof on the benefits.
Again, show me how kmdl scales. A university/enterprise environment is not a 3rd party extras repository.
And please consider that you are endorsing a standard for RHEL that is known to break the yum kmod plugin when it comes to GFS/cman dependencies, which is the only place where FC or RHEL really use kernel modules.
You haven't addressed all my points either.
Should Fedora's heritage to RHEL be a completely broken cluster/gfs setup or should we wait until RHEL's QA addresses upgradability, and dumps the current scheme then? Or worse, have the customers find out? -- Axel.Thimm at ATrpms.net
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
Again, show me how kmdl scales. A university/enterprise environment is not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to kmdl at work (speaking of thousands of systems here) rather successfully for several years. And like I stated previously as well, this is just for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing kernel modules and the depsolver+plugin to handle them which need to "scale": a plugin can be smart enough to skip the kernel update if no corresponding kernel module for the new version can be found, or abort the entire update. But you'll need plugins for both schemes to catch the situation where somehow a new kernel slipped out without having kernel modules for it available, otherwise you can end up with unbootable system.
- Panu -
On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote:
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
Again, show me how kmdl scales. A university/enterprise environment is not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to kmdl at work (speaking of thousands of systems here) rather successfully for several years. And like I stated previously as well, this is just for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing kernel modules and the depsolver+plugin to handle them which need to "scale": a plugin can be smart enough to skip the kernel update if no corresponding kernel module for the new version can be found, or abort the entire update. But you'll need plugins for both schemes to catch the situation where somehow a new kernel slipped out without having kernel modules for it available, otherwise you can end up with unbootable system.
monkey-wrench question:
what happens if both versions of a kernel module work on the available kernel but work with different versions of the userland tools?
-sv
On Mon, 2006-08-14 at 16:16 -0400, seth vidal wrote:
On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote:
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
Again, show me how kmdl scales. A university/enterprise environment is not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to kmdl at work (speaking of thousands of systems here) rather successfully for several years. And like I stated previously as well, this is just for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing kernel modules and the depsolver+plugin to handle them which need to "scale": a plugin can be smart enough to skip the kernel update if no corresponding kernel module for the new version can be found, or abort the entire update. But you'll need plugins for both schemes to catch the situation where somehow a new kernel slipped out without having kernel modules for it available, otherwise you can end up with unbootable system.
monkey-wrench question:
what happens if both versions of a kernel module work on the available kernel but work with different versions of the userland tools?
S**t hits the fan, that's what happens... and neither scheme can protect against that. Similar things can happen with the main kernel itself.. you can update the kernel along with a userland (hal, udev or such) package which is incompatible with the running kernel yet rpm dependencies are satisfied.
Runtime dependencies/provides would help a bit but then you'd have unresolvable deps on all the non-running kernels -> doesn't work either.
- Panu -
On Monday 14 August 2006 16:16, seth vidal wrote:
monkey-wrench question:
what happens if both versions of a kernel module work on the available kernel but work with different versions of the userland tools?
Heee! You gotta go and make it difficult don't you... (:
I haven't the brain bandwidth to think on this issue currently. Lets just try to Not Do This, as it hurts when I poke myself in the eyeball w/ my pen.
On Mon, Aug 14, 2006 at 04:36:41PM -0400, Jesse Keating wrote:
On Monday 14 August 2006 16:16, seth vidal wrote:
monkey-wrench question:
what happens if both versions of a kernel module work on the available kernel but work with different versions of the userland tools?
Heee! You gotta go and make it difficult don't you... (:
I haven't the brain bandwidth to think on this issue currently. Lets just try to Not Do This, as it hurts when I poke myself in the eyeball w/ my pen.
-- Jesse Keating Release Engineer: Fedora
Is it worth documenting this in the guidelines?
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Mon, Aug 14, 2006 at 04:16:22PM -0400, seth vidal wrote:
On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote:
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
Again, show me how kmdl scales. A university/enterprise environment is not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to kmdl at work (speaking of thousands of systems here) rather successfully for several years. And like I stated previously as well, this is just for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing kernel modules and the depsolver+plugin to handle them which need to "scale": a plugin can be smart enough to skip the kernel update if no corresponding kernel module for the new version can be found, or abort the entire update. But you'll need plugins for both schemes to catch the situation where somehow a new kernel slipped out without having kernel modules for it available, otherwise you can end up with unbootable system.
monkey-wrench question:
what happens if both versions of a kernel module work on the available kernel but work with different versions of the userland tools?
Can you explain? Do you mean two subsequent package versions of a kernel module, e.g. a version bump in the module's versioning side?
On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote:
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
Again, show me how kmdl scales. A university/enterprise environment is not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to kmdl at work (speaking of thousands of systems here) rather successfully for several years. And like I stated previously as well, this is just for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing kernel modules and the depsolver+plugin to handle them which need to "scale": a plugin can be smart enough to skip the kernel update if no corresponding kernel module for the new version can be found, or abort the entire update. But you'll need plugins for both schemes to catch the situation where somehow a new kernel slipped out without having kernel modules for it available, otherwise you can end up with unbootable system.
- Panu -
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
Panu,
I can agree with this. Can you point out some working code?
Jack
On Mon, 2006-08-14 at 16:30 -0400, Jack Neely wrote:
On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote:
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
Again, show me how kmdl scales. A university/enterprise environment is not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to kmdl at work (speaking of thousands of systems here) rather successfully for several years. And like I stated previously as well, this is just for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing kernel modules and the depsolver+plugin to handle them which need to "scale": a plugin can be smart enough to skip the kernel update if no corresponding kernel module for the new version can be found, or abort the entire update. But you'll need plugins for both schemes to catch the situation where somehow a new kernel slipped out without having kernel modules for it available, otherwise you can end up with unbootable system.
Panu,
I can agree with this. Can you point out some working code?
The kernel-module plugin for apt in FE does something like that (it'll warn you in the above situation, could be made to block the update of course), but it only works with old fedora.us/livna.org style kernel-module-foo-`uname -r` packages, IIRC would need some tweaking for kmdl. I haven't bothered updating my plugins for any new schemes as I've waited for this very battle to sort itself out some day :)
- Panu -
On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote:
But you'll need plugins for both schemes to catch the situation where somehow a new kernel slipped out without having kernel modules for it available, otherwise you can end up with unbootable system.
The kmdl plugin has two modes that cover that:
o yum install: Only triggers kmdl coinstallation if a kernel will be installed in this transactions and only for this kernel
o yum update: Check for new available kmdls for already installed kernels
kmdls will by definition - be it a 3rd party or an ISV/ISH - be shipped delayed. Maybe not for RHEL where selected partners get early access to final bits to prepare their add-ons, but certainly for non-premioum partners and for all Fedora land.
Therefore any plugin needs to be able to asyncronously fill the gaps.
On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
a) kernel module scheme needs uname-r-in-name
+/-0 currently if we only work for Fedora here.
-1 currently if we want the same stuff in RHEL and Fedora -- the "uname -r" is not that important with the kabi stuff and the problem should be fixed properly.
Note the word "currently".
b) kernel module scheme needs one-specfile approach (for both usreland and kernel modules)
-1 ; Reasons:
- changes only in the kmod will require that the userland packages gets
rebuild, too. That unnecessary. Yes, it can be prevented manually. But we would have to make sure that SRPMs for the old userland packages stay in the repo; and we would need special handling in the buildsys -> can of worms.
- people during the last kmod development didn't like having spec files
with a lot of
%if userland do stuff to build userland #endif %if module do stuff to build kmod #endif
- Because the name of the SRPM doesn't change when you rebuild stuff for
a newly released kernel the name of the debuginfo packages does also not change. So with a one-specfile approach we'd have to
-- created manually; we tried that during the development of the kmod standard. We didn't like it
or
-- that the release in increased everytime so the new debuginfo packages gets a new name -- creates the SRPMS problem described above
c) kernel module scheme needs to be kernel agnostic (both version *and* flavour)
+1 -- They are agnostic already. The current hardwiring in the spec file is only a temporary solution until we have proper support in the buildsys. Yes, there is one place in "kmodtool" where the flavours are hardcoded for users that rebuild kmods manually to prevent that they do something wrong.
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
-1 -- we took about half a year to develop the current standard for FE. I'm not going to switch to something where besides Axel no one of the people around has practical experiences
in a hurry
without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
after test2
shortly before RHEL beta 1 (or is it out already?)
I'd even tend to say: We shouldn't change what was discussed below "a)" (see above) at this point. To risky IMHO.
e) [...] Requires a positive vote on a-d) [...]
I had to many -1 up to here, so I'm stopping now ;-)
CU thl
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
I'm with Thorsten.
-1
*) We are way too late to implement a completely new kernel module for FE6/FC6 and RHEL 5. We were on schedule with the kmod scheme. But alas, I've not coded more things because I've been practicing my email skills. (Site point d)
*) I also site the scalability concerns.
Jack
On Friday 11 August 2006 06:58, Axel Thimm wrote:
I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme.
Perhaps I'm dumb, but after reading your wiki page I'm still not seeing where the current scheme really falls over. We have kmod packages treated like kernel packages in that they are install rather than upgrade. This is the same way that the kernel is handled, and if people do silly things with the rpm command line they can break their kernel just as easily as they can break their kernel modules. We have this handling in yum, which is the basis of every depsolver we support in Fedora / Red Hat. Yum is used by pup, puplet, pirut, and anaconda. All of these make use of the special casing we have in Yum and handle kmods correctly by installing rather than upgrading them. If other depsolvers don't, well that's really too bad and its up to those depsolvers to handle the packages correctly like they (should) handle kernel packages correctly.
So, I guess I'm being dumb, and I need it spelled out in big foam letters as I'm just not getting it, and thus I can't vote on it.
On Mon, Aug 14, 2006 at 01:19:32PM -0400, Jesse Keating wrote:
On Friday 11 August 2006 06:58, Axel Thimm wrote:
I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme.
Perhaps I'm dumb, but after reading your wiki page I'm still not seeing where the current scheme really falls over. We have kmod packages treated like kernel packages in that they are install rather than upgrade. This is the same way that the kernel is handled, and if people do silly things with the rpm command line they can break their kernel just as easily as they can break their kernel modules.
No, the issue is that kernel modules packages are neither to be "coinstalled", nor to be "upgraded" if the package entity is not disambiguated w/ uname-r-in-name
I've give such an exmaple before, try writing down an rpm command for the following situation:
Installed:
kernel-a module-2-for-a
kernel-b module-1-for-b
Now try to install module-2-for-b. For kmdls it's just rpm -U. For kmods it's impossible, you need to coinstall with module-2-for-a but upgrade module-1-for-b.
That's why every depsolver suddenly needs a plugin to do anything at all with kmods. The plugin needs to take this awkward situation in account and undo things that yum considered sane to do (but yum was only following rpm logic).
But the argument goes on that once you pull in a package "by mistake" you cannot undo it unless it is trivial e.g. has no further package depedencies like requires/obsoletes/conflict. These cascade further changes in yum's dependency resolver and undoing them in a plugin effectivly lead to redesigning yum in the plugin.
Currently the plugin assumes that is not the case, which is the case with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will fail in these cases.
And any plugin for any other depsolver will fail the same and rpm doesn't have plugins. The net result is a half-working yum, borken rpm, broken smart etc.
In comtrast if the scheme respects rpm rules like the kmdl scheme does you don't need to undo yum's work, just add the coinstall support. It turns out that the plugin for kmdls was less than half the current plugin for kmods which performs less and is still broken as outlined above.
We have this handling in yum, which is the basis of every depsolver we support in Fedora / Red Hat. Yum is used by pup, puplet, pirut, and anaconda. All of these make use of the special casing we have in Yum and handle kmods correctly by installing rather than upgrading them.
Thanks for the list. This means all of them are currently broken as outlined. And all of them can be fixed by following basic rpm rules like the kmdls do. The key point here is uname-r-in-name.
If other depsolvers don't, well that's really too bad and its up to those depsolvers to handle the packages correctly like they (should) handle kernel packages correctly.
I agree, if rpm and yum/pup/etc *could* deal with it, but they don't.
So, I guess I'm being dumb, and I need it spelled out in big foam letters as I'm just not getting it, and thus I can't vote on it.
Is the example above & argumentation clear? If yes, and the wiki is not please suggest where to inject an example or soem more working in the wiki.
On Monday 14 August 2006 14:16, Axel Thimm wrote:
No, the issue is that kernel modules packages are neither to be "coinstalled", nor to be "upgraded" if the package entity is not disambiguated w/ uname-r-in-name
I've give such an exmaple before, try writing down an rpm command for the following situation:
Installed:
kernel-a module-2-for-a
kernel-b module-1-for-b
Now try to install module-2-for-b. For kmdls it's just rpm -U. For kmods it's impossible, you need to coinstall with module-2-for-a but upgrade module-1-for-b.
That's why every depsolver suddenly needs a plugin to do anything at all with kmods. The plugin needs to take this awkward situation in account and undo things that yum considered sane to do (but yum was only following rpm logic).
Seems to me that we're really trying to beat around a deficiency in RPM. Creating whole new packages for every single kernel release is insane. New cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our entire infrastructure is based around the name of a package. Changing that for every single kernel update, or special casing it in every system is just silly. REALLY silly. I will absolutely vote against it.
But the argument goes on that once you pull in a package "by mistake" you cannot undo it unless it is trivial e.g. has no further package depedencies like requires/obsoletes/conflict. These cascade further changes in yum's dependency resolver and undoing them in a plugin effectivly lead to redesigning yum in the plugin.
Currently the plugin assumes that is not the case, which is the case with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will fail in these cases.
I have read these two paragraphs 5 times, and I still don't understand what you are saying. Examples work wonders. I'm lost in hyperbole land.
And any plugin for any other depsolver will fail the same and rpm doesn't have plugins. The net result is a half-working yum, borken rpm, broken smart etc.
In comtrast if the scheme respects rpm rules like the kmdl scheme does you don't need to undo yum's work, just add the coinstall support. It turns out that the plugin for kmdls was less than half the current plugin for kmods which performs less and is still broken as outlined above.
You're working around an issue in rpm by creating new packages all the time. That's not a solution, that's an ugly hack.
We have this handling in yum, which is the basis of every depsolver we support in Fedora / Red Hat. Yum is used by pup, puplet, pirut, and anaconda. All of these make use of the special casing we have in Yum and handle kmods correctly by installing rather than upgrading them.
Thanks for the list. This means all of them are currently broken as outlined. And all of them can be fixed by following basic rpm rules like the kmdls do. The key point here is uname-r-in-name.
Or, instead of introducing the insanity of uname-r in name, we can put effort into adjusting rpm and yum to handle this sort of package situation correctly.
If other depsolvers don't, well that's really too bad and its up to those depsolvers to handle the packages correctly like they (should) handle kernel packages correctly.
I agree, if rpm and yum/pup/etc *could* deal with it, but they don't.
So, I guess I'm being dumb, and I need it spelled out in big foam letters as I'm just not getting it, and thus I can't vote on it.
Is the example above & argumentation clear? If yes, and the wiki is not please suggest where to inject an example or soem more working in the wiki.
Thanks, I've heard enough to make up my mind. -1 on the entire thing.
On Mon, 2006-08-14 at 14:31 -0400, Jesse Keating wrote:
On Monday 14 August 2006 14:16, Axel Thimm wrote:
No, the issue is that kernel modules packages are neither to be "coinstalled", nor to be "upgraded" if the package entity is not disambiguated w/ uname-r-in-name
I've give such an exmaple before, try writing down an rpm command for the following situation:
Installed:
kernel-a module-2-for-a
kernel-b module-1-for-b
Now try to install module-2-for-b. For kmdls it's just rpm -U. For kmods it's impossible, you need to coinstall with module-2-for-a but upgrade module-1-for-b.
That's why every depsolver suddenly needs a plugin to do anything at all with kmods. The plugin needs to take this awkward situation in account and undo things that yum considered sane to do (but yum was only following rpm logic).
Seems to me that we're really trying to beat around a deficiency in RPM. Creating whole new packages for every single kernel release is insane. New cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our entire infrastructure is based around the name of a package. Changing that for every single kernel update, or special casing it in every system is just silly. REALLY silly. I will absolutely vote against it.
The entire infrastructure is based around the name of the SOURCE package which remains the same with kmdls just like with kmods, normal subpackage splits etc.
- Panu -
On Monday 14 August 2006 14:41, Panu Matilainen wrote:
The entire infrastructure is based around the name of the SOURCE package which remains the same with kmdls just like with kmods, normal subpackage splits etc.
Hrm, ok, so less impact on infrastructure. Its still a package that changes its name potentially with every rebuild which is still no good in my book. ESPECIALLY as a hack to work around other issues.
On Mon, 2006-08-14 at 14:54 -0400, Jesse Keating wrote:
On Monday 14 August 2006 14:41, Panu Matilainen wrote:
The entire infrastructure is based around the name of the SOURCE package which remains the same with kmdls just like with kmods, normal subpackage splits etc.
Hrm, ok, so less impact on infrastructure. Its still a package that changes its name potentially with every rebuild which is still no good in my book. ESPECIALLY as a hack to work around other issues.
It's not much worse than openssl :D
Seriously, yes the changing package names are a a bit of a pain, silly things like scripts to prune out old packages from a repo suddenly need to be aware of version-in-name thing as well etc.
Both schemes have their good points and weak points and both have been shown to work most of the time in real world, that's why I suggested flipping a coin over it earlier in this thread...
- Panu -
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Or, instead of introducing the insanity of uname-r in name, we can JK> put effort into adjusting rpm and yum to handle this sort of JK> package situation correctly.
It seems like what we really need is some sort of two-dimensional versioning. I guess everyone will just laugh at me for suggesting it, but for a plugin/module "foo" having version "M" which works with "packageA" version "N", just call it "packageA-module-foo-M,N", teach the depsolvers how to deal with it, and get on with life.
- J<
Jason L Tibbitts III wrote:
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Or, instead of introducing the insanity of uname-r in name, we can JK> put effort into adjusting rpm and yum to handle this sort of JK> package situation correctly.
It seems like what we really need is some sort of two-dimensional versioning. I guess everyone will just laugh at me for suggesting it, but for a plugin/module "foo" having version "M" which works with "packageA" version "N", just call it "packageA-module-foo-M,N", teach the depsolvers how to deal with it, and get on with life.
It may be just me, but I would categorize the latter effort closer to insanity than the former.
-- Rex
On Mon, Aug 14, 2006 at 02:15:59PM -0500, Jason L Tibbitts III wrote:
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Or, instead of introducing the insanity of uname-r in name, we can JK> put effort into adjusting rpm and yum to handle this sort of JK> package situation correctly.
It seems like what we really need is some sort of two-dimensional versioning. I guess everyone will just laugh at me for suggesting it,
I'm not, that's exactly the issue here.
but for a plugin/module "foo" having version "M" which works with "packageA" version "N", just call it "packageA-module-foo-M,N", teach the depsolvers how to deal with it, and get on with life.
That can take half a decade, so we should find a solution for now and lobby with our experiences for rpmng's design.
This is off-topic, but I really thing that at some time in the future our group could start thinking about setting up specifications for a new package manager trying to learn from rpm's deficiencies and trying to unearth a project for that.
On Mon, Aug 14, 2006 at 02:31:41PM -0400, Jesse Keating wrote:
Seems to me that we're really trying to beat around a deficiency in RPM.
Yes, that's pinned down nicely by tibbs as making rpm two-dimensional. But that's what we've got and it is not going to change for a long time.
Creating whole new packages for every single kernel release is insane. New cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our entire infrastructure is based around the name of a package. Changing that for every single kernel update, or special casing it in every system is just silly. REALLY silly. I will absolutely vote against it.
As outlined by Panu this is not the case. In fact the infrastructure and maintenance is halfed as there is really only one name, not two like it is today. The kmod standard need two bugzilla entries per package, two owner entries, two cvs modules. kmdls only need one.
So may I take that as a vote in favour of a one-sepcfile design? :)
But the argument goes on that once you pull in a package "by mistake" you cannot undo it unless it is trivial e.g. has no further package depedencies like requires/obsoletes/conflict. These cascade further changes in yum's dependency resolver and undoing them in a plugin effectivly lead to redesigning yum in the plugin.
Currently the plugin assumes that is not the case, which is the case with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will fail in these cases.
I have read these two paragraphs 5 times, and I still don't understand what you are saying. Examples work wonders. I'm lost in hyperbole land.
OK, suppose some kernel module scheme like kmod works against yum's depsolving. Since yum adhears to rpm orderign and the kmod scheme doesn't that's not difficult to achive.
Now the setup is such that yum will either install too many or to few packages. Too few is good, you can always add to yum's transaction and yum will compute the new dependencies. Too much is really bad, because the pulled in packages will pull in more packages or push out others (due to Requires/Obsoletes/Conflicts).
Let's get to an example:
ipw3945 version X (the exmaple is real, but don't have me lookup the true versions please) requires ipw3945d Y (a userland daemon). ipw3945 X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X this will have pulled in ipw3945d-Y. Undoing this in some plugin code would only remove ipw3945-X, not ipw3945d-Y.
Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc.
You're working around an issue in rpm by creating new packages all the time. That's not a solution, that's an ugly hack.
The packages are really distinct and have different functionality and depednencies. You need both evrs in the total package filename. Moving them to the rpm name turns to solve 95% of all issues. And the fears on increased infrastructure are unbased, you even save some.
Thanks, I've heard enough to make up my mind. -1 on the entire thing.
OK, is that still the case after having seen that infrastructure is not bitten?
On Monday 14 August 2006 20:35, Axel Thimm wrote:
As outlined by Panu this is not the case. In fact the infrastructure and maintenance is halfed as there is really only one name, not two like it is today. The kmod standard need two bugzilla entries per package, two owner entries, two cvs modules. kmdls only need one.
So may I take that as a vote in favour of a one-sepcfile design? :)
Absolutely not. Userland is separate from the kernel module. Forcing the userland crud to be rebuilt and reshipped and redownloaded each and every time the kernel is updated (or kabi changes) is ridiculous. There is a big difference between a set of userland+kmod for each module set and a new package each and every time the kernel is updated.
But the argument goes on that once you pull in a package "by mistake" you cannot undo it unless it is trivial e.g. has no further package depedencies like requires/obsoletes/conflict. These cascade further changes in yum's dependency resolver and undoing them in a plugin effectivly lead to redesigning yum in the plugin.
Currently the plugin assumes that is not the case, which is the case with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will fail in these cases.
I have read these two paragraphs 5 times, and I still don't understand what you are saying. Examples work wonders. I'm lost in hyperbole land.
OK, suppose some kernel module scheme like kmod works against yum's depsolving. Since yum adhears to rpm orderign and the kmod scheme doesn't that's not difficult to achive.
Now the setup is such that yum will either install too many or to few packages. Too few is good, you can always add to yum's transaction and yum will compute the new dependencies. Too much is really bad, because the pulled in packages will pull in more packages or push out others (due to Requires/Obsoletes/Conflicts).
Let's get to an example:
ipw3945 version X (the exmaple is real, but don't have me lookup the true versions please) requires ipw3945d Y (a userland daemon). ipw3945 X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X this will have pulled in ipw3945d-Y. Undoing this in some plugin code would only remove ipw3945-X, not ipw3945d-Y.
Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc.
Are you really going to versionize the entire userland? Have a separate daemon for each possible module version? How does THAT work at boot time? When your userland moves beyond what your kernel can handle (udev updates, etc..) perhaps its time to update your kernel. If you can't, well then perhaps you shouldn't be using a distribution that moves quickly. And if you're changing the userland that fast on a RHEL product, well then you're using it wrong and tough ditty.
You're working around an issue in rpm by creating new packages all the time. That's not a solution, that's an ugly hack.
The packages are really distinct and have different functionality and depednencies. You need both evrs in the total package filename. Moving them to the rpm name turns to solve 95% of all issues. And the fears on increased infrastructure are unbased, you even save some.
Thanks, I've heard enough to make up my mind. -1 on the entire thing.
OK, is that still the case after having seen that infrastructure is not bitten?
Nope. The infrastructure bits were only a small part of my concern. Still a -1.
On Mon, Aug 14, 2006 at 09:02:01PM -0400, Jesse Keating wrote:
On Monday 14 August 2006 20:35, Axel Thimm wrote:
As outlined by Panu this is not the case. In fact the infrastructure and maintenance is halfed as there is really only one name, not two like it is today. The kmod standard need two bugzilla entries per package, two owner entries, two cvs modules. kmdls only need one.
So may I take that as a vote in favour of a one-sepcfile design? :)
Absolutely not. Userland is separate from the kernel module. Forcing the userland crud to be rebuilt and reshipped and redownloaded each and every time the kernel is updated (or kabi changes) is ridiculous. There is a big difference between a set of userland+kmod for each module set and a new package each and every time the kernel is updated.
Yes, I agree, so it's nice that this is not the case with kmdls :)
Just go over to ATrpms and have a look at the packages. You have many misunderstandings on the kmdl proposal and maybe looking at real packages may help. Testing them out with the kmdl plugin would be even better.
Let's get to an example:
ipw3945 version X (the exmaple is real, but don't have me lookup the true versions please) requires ipw3945d Y (a userland daemon). ipw3945 X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X this will have pulled in ipw3945d-Y. Undoing this in some plugin code would only remove ipw3945-X, not ipw3945d-Y.
Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc.
Are you really going to versionize the entire userland?
No, the versions above are not kernel versions, you misinterpreted them. The example is all within the same kernel, say 2.6.17-Z if you like.
Have a separate daemon for each possible module version?
Again a misinterpretation. The daemon has nothing to do with the kmdl scheme, it's part of the project. There is no daemon in the design. But you asked for real life examples and that is one. Instead of a daemon this might be the firmware packages etc, and no - the kmdls scheme doesn't need firmwares per module, neither. :)
How does THAT work at boot time? When your userland moves beyond what your kernel can handle (udev updates, etc..) perhaps its time to update your kernel. If you can't, well then perhaps you shouldn't be using a distribution that moves quickly. And if you're changing the userland that fast on a RHEL product, well then you're using it wrong and tough ditty.
All in the wrong context, you made some wrong assumptions and ended in a devastating picture of the kmdl scheme. I shudder myself from such a vision. :)
Thanks, I've heard enough to make up my mind. -1 on the entire thing.
Nope. The infrastructure bits were only a small part of my concern. Still a -1.
You are misinterpreting my explanations beyond recognition, so perhaps I should simply accept that. ;) If doubts come up, you know where to find me.
It's 2 in favour 1 against for now. Still looking for 4 people which will give their +1. :)
Hi all!
I think we fight to many battles at once. So let's start concentrate on one of the easy ones first. As the uname -r debatte is likely to take some time I choose the "one-spec approach" one.
I'd like to propose that the packaging group rejects this part from Axels scheme:
Axel Thimm schrieb:
b) kernel module scheme needs one-specfile approach (for both usreland and kernel modules)
We currently have a split with the current kmod standard, e.g. userland and kmod have their own packages (spot was one of the drivers behind it IIRC).
Both approaches have small advantages and disadvantages (I don't think mention the pros and cons of each one here makes much sense), but there is nothing earth scattering that make one of the two much better.
But the split - was agreed on some month ago by FESCo (the predecessor of the packaging committee in this respect). Why change it again without a good reason? - changeing all the existing specs over to a one-specfile approach will be a lot of work because -- it's already in production (in FE and LVN) -- we have a lot of packages under review that use the split approach; -- is time critical because we're already after test2 - packagers and some reviewers are familiar with it already - it works in the buildsystem already -- the kmdl scheme would need special handling that needs to be programmed
So changing this will be lot's of trouble without a benefit. So let's reject this part now.
CU thl
On Tue, Aug 15, 2006 at 07:42:53AM +0200, Thorsten Leemhuis wrote:
I think we fight to many battles at once. So let's start concentrate on one of the easy ones first. As the uname -r debatte is likely to take some time I choose the "one-spec approach" one.
-- it's already in production (in FE and LVN) -- we have a lot of packages under review that use the split approach;
There is exactly one (1) package in Fedora and lives only in FE5.
-- is time critical because we're already after test2
For this very one package ...
- packagers and some reviewers are familiar with it already
I only count Ville and you.
- it works in the buildsystem already -- the kmdl scheme would need
special handling that needs to be programmed
In a previous mail you admitted not being kernel agnostic yet because otherwise your kmods won't build. And I offered adding kmdl support to the buildsystem.
So changing this will be lot's of trouble without a benefit. So let's reject this part now.
No, please don't listen to the devil. :)
Thorsten, this is part of the voting, it will be voted upon, if you allow people to do so. This guerilla tactics are becoming ugly.
Axel Thimm schrieb:
On Tue, Aug 15, 2006 at 07:42:53AM +0200, Thorsten Leemhuis wrote:
I think we fight to many battles at once. So let's start concentrate on one of the easy ones first. As the uname -r debatte is likely to take some time I choose the "one-spec approach" one.
-- it's already in production (in FE and LVN) -- we have a lot of packages under review that use the split approach;
There is exactly one (1) package in Fedora and lives only in FE5.
+2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod)
+7 under review
+6 in lvn
-- is time critical because we're already after test2
For this very one package ...
It's to late for FC6 and RHEL IMHO.
- packagers and some reviewers are familiar with it already
I only count Ville and you.
7 packages under review (from different people afaics), jcmasters, nirik, f13, jeremy, tibbs
- it works in the buildsystem already -- the kmdl scheme would need
special handling that needs to be programmed
In a previous mail you admitted not being kernel agnostic yet because otherwise your kmods won't build.
The hardcoded stuff it optional and it works *now*.
So changing this will be lot's of trouble without a benefit. So let's reject this part now.
No, please don't listen to the devil. :)
:)
Thorsten, this is part of the voting, it will be voted upon, if you allow people to do so.
Sure.
This guerilla tactics are becoming ugly.
That's why I think it's time that spot as leader of this group IMHO jumps in. Otherwise we waste a lot of time arguing without results.
CU thl
On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote:
There is exactly one (1) package in Fedora and lives only in FE5.
+2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod)
+7 under review
+6 in lvn
-67 in ATrpms
Looks like you're raising this to an ATrpms vs livna issue? I thought we wanted to merge ...
This guerilla tactics are becoming ugly.
That's why I think it's time that spot as leader of this group IMHO jumps in. Otherwise we waste a lot of time arguing without results.
When he showed he tends to a uname-r-in-version solution you seem to have activated all your muscles against it even though you promised otherwise before.
You still have your chance to reject it in fesco.
Axel Thimm schrieb:
On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote:
There is exactly one (1) package in Fedora and lives only in FE5.
+2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod) +7 under review +6 in lvn
-67 in ATrpms
Looks like you're raising this to an ATrpms vs livna issue? I thought we wanted to merge ...
I hope we can still merge.
This guerilla tactics are becoming ugly.
That's why I think it's time that spot as leader of this group IMHO jumps in. Otherwise we waste a lot of time arguing without results.
When he showed he tends to a uname-r-in-version solution you seem to have activated all your muscles against it even though you promised otherwise before.
I activated all my muscles for a complete switch from the current kmod standard to something else because
- the current kmod standard was developed in half a year with a lot of work involved from me, scop, jeremy, warren, f13 and others. jcmaster (and other people I never have heard of) invested a lot of time in it for RHEL. Throwing that completely away would be painful, but I would do that if there are good reasons for it. I can't see them.
Question to scop, jeremy, warren, f13, jcmaster: Do you see any reasons why we should throw away everything?
- throwing it away this short before RHEL beta1 and FC6test3 is IMHO not acceptable -- especially because we don't have many experiences with it (well, scop, I and some others have experiences with the "uname -r" scheme, but at least mine were not as good as yours).
Back to the uname-r-in-version thing: Well, I think the uname-r-in-version solution is not the best solution. But as I said earlier in this thread:
"0" (e.g. undecided) currently if we only work for Fedora here. But that would mean that we change kmodtool to handle it as spot cuggested in the wiki.
"-1" currently if we want the same stuff in RHEL and Fedora -- the "uname -r" is not that important with the kabi stuff and the problem should be fixed properly.
Note the word "currently" and "undecided".
You still have your chance to reject it in fesco.
I'm not doing the FESCo decisions alone.
CU thl
Thorsten Leemhuis schrieb:
Axel Thimm schrieb:
On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote:
This guerilla tactics are becoming ugly.
That's why I think it's time that spot as leader of this group IMHO jumps in. Otherwise we waste a lot of time arguing without results.
When he showed he tends to a uname-r-in-version solution you seem to have activated all your muscles against it even though you promised otherwise before.
I activated all my muscles for
s/for/against/ -- but that's pretty obvious probably ;-)
a complete switch from the current kmod standard to something else because
[...]
CU thl
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
I suggest to vote through email [...]
5 voted, 5 still to go. Can the remaining committee members do their voting business, please? Maybe we get this rejected and all can be happy again ;)
http://fedoraproject.org/wiki/AxelThimm/kmdls/voting
I added Ville's votes (and copied them verbatim for Toshio on his wish) but the first because he made it indirectly dependent on the outcome: Ville & Toshio you need to decide on the first item, if you are not sure better reject than accept, but don't conditionalize, it makes vote counting difficult. :)
Note: Don't use "0", it's the same as "-1" in fedora-packaging.
On Wed, Aug 16, 2006 at 07:44:31PM +0200, Axel Thimm wrote:
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
I suggest to vote through email [...]
5 voted, 5 still to go. Can the remaining committee members do their voting business, please? Maybe we get this rejected and all can be happy again ;)
http://fedoraproject.org/wiki/AxelThimm/kmdls/votingI added Ville's votes (and copied them verbatim for Toshio on his wish) but the first because he made it indirectly dependent on the outcome: Ville & Toshio you need to decide on the first item, if you are not sure better reject than accept, but don't conditionalize, it makes vote counting difficult. :)
Note: Don't use "0", it's the same as "-1" in fedora-packaging.
As a committee we need to decide on certain items either positive or negative. Allowing discussion before voting is OK, but having a stalled voting over weeks isn't really an advertisment for our work.
Please vote within the next day until Wed 16:00UTC. I'll consider the missing votes as "-1", but mark them as "0" to distinguish from the actual votes.
On Tue, 2006-08-22 at 16:56 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 07:44:31PM +0200, Axel Thimm wrote:
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
I suggest to vote through email [...]
5 voted, 5 still to go. Can the remaining committee members do their voting business, please? Maybe we get this rejected and all can be happy again ;)
http://fedoraproject.org/wiki/AxelThimm/kmdls/votingI added Ville's votes (and copied them verbatim for Toshio on his wish) but the first because he made it indirectly dependent on the outcome: Ville & Toshio you need to decide on the first item, if you are not sure better reject than accept, but don't conditionalize, it makes vote counting difficult. :)
Note: Don't use "0", it's the same as "-1" in fedora-packaging.
As a committee we need to decide on certain items either positive or negative. Allowing discussion before voting is OK, but having a stalled voting over weeks isn't really an advertisment for our work.
Please vote within the next day until Wed 16:00UTC. I'll consider the missing votes as "-1", but mark them as "0" to distinguish from the actual votes.
I vote -1 on all items, not because KMDL has anything incorrect, but because I do not wish to overhaul an existing standard, rather than correct the flaws present in it.
~spot
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
Hi,
I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme.
a) kernel module scheme needs uname-r-in-name
b) kernel module scheme needs one-specfile approach (for both usreland and kernel modules)
c) kernel module scheme needs to be kernel agnostic (both version *and* flavour)
d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c)
e) Adoption of kmdl interface scheme as used at ATrpms and outlined on http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive vote on a-d)
f) Assignment to kmdl-task force to integrate kmdl support into the buildsystems used by Fedora (myself volunteering). Requires a positive vote on a-e)
g) Allow kmdl package submissions to Fedora Core/Extras. Requires a positive vote on a-f)
Without voting, but dependent on vote results: Assist in GFS kmdl packaging (altready done at FC4 times, needs to resurface).
After a long and painful struggle this matter reached an end. The voting result is that none of these passes. Also the voting participation indicates that this is not a topic this committee is interested in:
http://fedoraproject.org/wiki/AxelThimm/kmdls/voting
Almost half the members of this committee did not care to vote, some did not even comment on this matter at all. This is a sad thing. Not for the specific matter (which is sad, too), but because it was an item one of us worked his ass off to fulfill all possible incoming requests on documentation, explanation, use cases, examples, synopsis, whatever, and the least one would expect would be to have more people vote.
It's ugly to see my efforts being rejected, but being ignored is even worse. </whine>
Almost half the members of this committee did not care to vote, some did not even comment on this matter at all. This is a sad thing. Not for the specific matter (which is sad, too), but because it was an item one of us worked his ass off to fulfill all possible incoming requests on documentation, explanation, use cases, examples, synopsis, whatever, and the least one would expect would be to have more people vote.
Indeed. It would have been nice to at least see people who are truly disinterested vote with a 0. (Note: I am excluding Ralf from this, as he's said he will be unavailable for the near future)
~spot
packaging@lists.fedoraproject.org
-
Axel Thimm -
Jack Neely -
Jason L Tibbitts III -
Jesse Keating -
Panu Matilainen -
Rex Dieter -
seth vidal -
Thorsten Leemhuis -
Tom Callaway