After weeks of discourse on IRC and mailing list discussions, we seem to be unable to make progress toward an amicable agreement.
What seems to be the issue is that RPM does not allow any clean solution to the kernel module packaging problem. Both kmod and kmdl are comprised of ugly hacks in order to overcome the design limitations of RPM. Both kmod and kmdl have pros and cons, and neither is a clearly agreed by all parties as being technically superior.
The FESCO side is disconcerted by this situation because a great deal of effort over years was put into making and ratifying today's kmod standard. On the other hand, there is some hope for middle-ground because of stated willingness to further revise kmod to overcome remaining limitations.
It is the decision of me, Max, and Spot, to put a hold on publishing any further kmod modules pending the result the Kernel Module Packaging Standard conference call. Time/date of this call is to be determined, but we are aiming for this Friday, August 18th at a time that is workable for both American EDT and Europe. Perhaps 1PM EDT would work, the usual timeslot of FESCO meetings? Perhaps this timeslot wont work. If you feel it is important to attend but you are unable to make this time, please make it known in this thread.
In order to make this meeting manageable, we must limit the number of attendees. Invited are the existing members of the Fedora Packaging Committee, Thorsten Leemhuis and certain Red Hat employees relevant to this discussion. Please talk to me directly if you have been an active contributor to this in the past but are not included in this invitee list.
My personal feeling is that it is way too late to throw out kmod, OTOH it is important that we discuss each point to see if kmod can be improved.
If the packaging committee cannot come to key agreements, then the matter will be escalated to the Fedora Project Board who will make the key decisions.
Warren Togami wtogami@redhat.com
Warren Togami schrieb:
After weeks of discourse on IRC and mailing list discussions,
[...]
In order to make this meeting manageable, we must limit the number of attendees. Invited are the existing members of the Fedora Packaging Committee, Thorsten Leemhuis and certain Red Hat employees relevant to this discussion. Please talk to me directly if you have been an active contributor to this in the past but are not included in this invitee list.
There were no discussions on IRC (Axel invited me once but I couldn't join it -- private matters were blocking, sorry). I really would prefer a IRC disussion over a Teleconference -- that's IMHO the better to coordinate and a lot easier for those of us that don't speak english that often.
CU thl
Thorsten Leemhuis wrote:
Warren Togami schrieb:
After weeks of discourse on IRC and mailing list discussions,
[...]
In order to make this meeting manageable, we must limit the number of attendees. Invited are the existing members of the Fedora Packaging Committee, Thorsten Leemhuis and certain Red Hat employees relevant to this discussion. Please talk to me directly if you have been an active contributor to this in the past but are not included in this invitee list.
There were no discussions on IRC (Axel invited me once but I couldn't join it -- private matters were blocking, sorry). I really would prefer a IRC disussion over a Teleconference -- that's IMHO the better to coordinate and a lot easier for those of us that don't speak english that often.
Hmm, good point about English, it could very well make it difficult for us to communicate. The idea of the teleconference was our crazy American idea. That's how we often do things...
The important thing is for someone neutral to drive the process, hopefully Spot can do it. The driver of this meeting must act as mediator. We must all stay away from recriminations and stick to the technical points. Go down all questions and concerns and discuss each point. If someone doesn't understand then implications must be explained.
Then matters must come down to a vote after context is understood.
Perhaps given this format, IRC may work better. We can think about this a bit more as we also figure out if all of the key players are available at that time on Friday. We'll see.
Warren Togami wtogami@redhat.com
Warren Togami schrieb:
Thorsten Leemhuis wrote:
Warren Togami schrieb:
After weeks of discourse on IRC and mailing list discussions,
[...]
In order to make this meeting manageable, we must limit the number of attendees. Invited are the existing members of the Fedora Packaging Committee, Thorsten Leemhuis and certain Red Hat employees relevant to this discussion. Please talk to me directly if you have been an active contributor to this in the past but are not included in this invitee list.
There were no discussions on IRC (Axel invited me once but I couldn't join it -- private matters were blocking, sorry). I really would prefer a IRC disussion over a Teleconference -- that's IMHO the better to coordinate and a lot easier for those of us that don't speak english that often.
Hmm, good point about English, it could very well make it difficult for us to communicate.
IRC IMHO has even one more benefit that would help in this especially in this case: You can paste URLs to mails in the archive or on the web.
Further: multiple people can write in parallel (that's a advantage and a disadvantage at the same time). A disadvantage of telephone conferences: they often consume all of your attention -- in an IRC-Meeing you can go afk for one minute if there is a need to and read what happened in between
The important thing is for someone neutral to drive the process, hopefully Spot can do it. The driver of this meeting must act as mediator. We must all stay away from recriminations and stick to the technical points. Go down all questions and concerns and discuss each point. If someone doesn't understand then implications must be explained.
Agreed.
Then matters must come down to a vote after context is understood.
Just to make sure: One vote per "technical point"?
Perhaps given this format, IRC may work better.
+1
We can think about this a bit more as we also figure out if all of the key players are available at that time on Friday. We'll see.
k
CU thl
On Wed, Aug 16, 2006 at 08:35:18AM +0200, Thorsten Leemhuis wrote:
Warren Togami schrieb:
Thorsten Leemhuis wrote:
Warren Togami schrieb:
After weeks of discourse on IRC and mailing list discussions,
[...]
In order to make this meeting manageable, we must limit the number of attendees. Invited are the existing members of the Fedora Packaging Committee, Thorsten Leemhuis and certain Red Hat employees relevant to this discussion. Please talk to me directly if you have been an active contributor to this in the past but are not included in this invitee list.
There were no discussions on IRC (Axel invited me once but I couldn't join it -- private matters were blocking, sorry). I really would prefer a IRC disussion over a Teleconference -- that's IMHO the better to coordinate and a lot easier for those of us that don't speak english that often.
Hmm, good point about English, it could very well make it difficult for us to communicate.
I wouldn't mind and the main disputants here are non-English natives both. It would be probably the rest not understanding our pronounciation ;)
IRC IMHO has even one more benefit that would help in this especially in this case: You can paste URLs to mails in the archive or on the web.
We can fire up an IRC session in parallel to paste in things.
Further: multiple people can write in parallel (that's a advantage and a disadvantage at the same time). A disadvantage of telephone conferences: they often consume all of your attention -- in an IRC-Meeing you can go afk for one minute if there is a need to and read what happened in between
That's the real disadvantage of IRC: You wait for someone's reply who went on doing other things and while waiting you decide to do other stuff yourself. In a typical IRC session there is a round-about in dialogs of 5/minute while voice gets up to 15/minute.
I'm in for any form, IRC sessions have the big advantage of being archivable and searchable.
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote:
After weeks of discourse on IRC and mailing list discussions, we seem to be unable to make progress toward an amicable agreement.
What seems to be the issue is that RPM does not allow any clean solution to the kernel module packaging problem. Both kmod and kmdl are comprised of ugly hacks in order to overcome the design limitations of RPM. Both kmod and kmdl have pros and cons, and neither is a clearly agreed by all parties as being technically superior.
The FESCO side is disconcerted by this situation because a great deal of effort over years was put into making and ratifying today's kmod standard. On the other hand, there is some hope for middle-ground because of stated willingness to further revise kmod to overcome remaining limitations.
As I didn't have the time to follow all these discussions and threads, and to have a basis for such an IRC-conference, I would appreciate if Axel and Thorsten could write up a "my proposal at one glance" outline.
I would be particularly interested in their proposals's macroscopic behavior and interaction with rpmbuild, mock, rpm -U|-I, the impact on yum/apt/smart.
If the packaging committee cannot come to key agreements, then the matter will be escalated to the Fedora Project Board who will make the key decisions.
"Order di Mufti" as we call this in German, the worst of all management principles :(
Ralf
On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote:
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: As I didn't have the time to follow all these discussions and threads, and to have a basis for such an IRC-conference, I would appreciate if Axel and Thorsten could write up a "my proposal at one glance" outline.
I setup an executive summary of the comparison for you and for other people external to the discussion until now who would like to join in on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
and the details remain under
http://fedoraproject.org/wiki/AxelThimm/kmdls
So if something looks unclear in the tabular summary please check the second link for a more verbose version.
I would be particularly interested in their proposals's macroscopic behavior and interaction with rpmbuild, mock, rpm -U|-I, the impact on yum/apt/smart.
I tried to add every issue that has been raised to date.
And I have even rated the issues in an objective and fair manner as possible (I added all arguments against kmdls and even rated them negative). I invite anyone to add his ratings, too. While the single items are all factually correct (nobody really denies the technical background anymore) the differences between kmdl and kmod opponents are in the personal weighing of consequences.
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
I setup an executive summary of the comparison for you and for other people external to the discussion until now who would like to join in on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
I'm almost certainly unable to join any meeting before next week (including tomorrow's packaging and fesco meetings) and will have only very limited access to mail during that time too. It's unlikely that my general opinion about this stuff would change, so it's not really necessary for me to attend the meeting -- don't postpone it for me.
To reiterate: if consensus says change is needed, and there's competent manpower available to take care of things *soon*, so be it. The only things I feel strongly about are that rejecting module packages from FC/FE altogether would be profoundly odd at this point, and that the scope of the discussion needs to be limited to whether uname-r gets moved to the packages' names and its direct unavoidable consequences -- the only real technical design issue. Everything else in the "kmdl" proposal is more or less cosmetics and implementation details, and adopting it would mean throwing away quite a bit of work (reinventing the wheel from the POV of the current scheme and its adopters) from several parties for questionable gain.
http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName This draft has potential.
If it comes down to a vote, mine can be registered as: * -1 for rejecting module packages * +0.5 for moving uname-r *if* there is strong evidence that it will be acceptable for all major stakeholders (Fedora, RHEL, kerneldrivers.org in particular), -0.5 otherwise * -1 to other kmdl change suggestions
(BTW, this is off topic, but if this discussion fails to produce useful widely accepted results, I wouldn't outright reject DKMS or DKMS-like mechanisms as an alternative; while these don't meet everyone's requirements, they'd be vastly better than nothing at all.)
While the single items are all factually correct
Strong words. The above summary and the detailed doc contains several inaccuracies and omissions (eg. about agnosticity, flexibility, buildsys support, kabi, support(ability) in other distros etc), luckily mostly in the less important parts. I guess this is due to not understanding all aspects of the current scheme and the environment it is designed to work in. I won't spend time detailing those because I don't have time to do that right now, and even if I had, IMO there are no real reasons to consider/discuss its adoption besides the uname-r move bit. (Yes, sucky statement, but shrug, it's the best I can do in the time I have available for this at the moment.)
Ville Skyttä schrieb:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
and that the scope of the discussion needs to be limited to whether uname-r gets moved to the packages' names and its direct unavoidable consequences -- the only real technical design issue.
I agree that this is the only "only real technical design issue" of the current standard. But I'd don't think that we hastily should change this detail. Two weeks should be enough to look at this precise problem closer and work out and test the solutions (one solution of course is uname-r, but I *currently* think it's not the best one -- especially not for RHEL, where the uname -r might be confusing). I roughly another way how this might be fixed in https://www.redhat.com/archives/fedora-packaging/2006-August/msg00086.html already.
Everything else in the "kmdl" proposal is more or less cosmetics and implementation details, and adopting it would mean throwing away quite a bit of
s/a bit/a lot of/ IMHO -- it were probably around 15 to 20 IRC meetings IIRC (probably even more) and a lot of traffic on the mailinglists where FESCo (including jeremy and spot) discussed each and every detail in depth. We even evaluated most of the stuff that's made different in the kmdl scheme during that phase. We for example looked at a debuginfo solution similar to the one in Axels kmdls and chose not to use it; we looked at a one srpm approach for both userland and kernel-module and decided to split. That are -- as scop outlined above -- implementation details that are already used in some packages in Extras, under Review for Extras and another repo that's using the same scheme. We IMHO shouldn't change them without a good reason.
work (reinventing the wheel from the POV of the current scheme and its adopters) from several parties for questionable gain.
Otherwise I'm strongly in agreement with that paragraph.
[...]
CU thl
On Wed, Aug 16, 2006 at 04:46:10PM +0300, Ville Skyttä wrote:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
- +0.5 for moving uname-r *if* there is strong evidence that it will be acceptable for all major stakeholders (Fedora, RHEL, kerneldrivers.org in particular), -0.5 otherwise
chicken and egg problem?
While the single items are all factually correct
Strong words. The above summary and the detailed doc contains several inaccuracies and omissions (eg. about agnosticity, flexibility, buildsys support, kabi, support(ability) in other distros etc), luckily mostly in the less important parts. I guess this is due to not understanding all aspects of the current scheme and the environment it is designed to work in. I won't spend time detailing those because I don't have time to do that right now, and even if I had, IMO there are no real reasons to consider/discuss its adoption besides the uname-r move bit. (Yes, sucky statement, but shrug, it's the best I can do in the time I have available for this at the moment.)
Yes, it's quite lame. If you accuse the write-up of inaccuracies/ommisions you have to go into details. Even defusing that it's not about the important parts is not enough.
No, really, I don't have time to waste myself, still I deliver for every statement I make. If you don't people may consider it FUD.
On Wed, 2006-08-16 at 16:46 +0300, Ville Skyttä wrote:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
I setup an executive summary of the comparison for you and for other people external to the discussion until now who would like to join in on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
I'm almost certainly unable to join any meeting before next week
Similar applies to me. I'll probably be unable to join any meeting before mid Sept. unless it takes place late at night CET.
To reiterate: if consensus says change is needed, and there's competent manpower available to take care of things *soon*, so be it. The only things I feel strongly about are that rejecting module packages from FC/FE altogether would be profoundly odd at this point, and that the scope of the discussion needs to be limited to whether uname-r gets moved to the packages' names and its direct unavoidable consequences -- the only real technical design issue. Everything else in the "kmdl" proposal is more or less cosmetics and implementation details, and adopting it would mean throwing away quite a bit of work (reinventing the wheel from the POV of the current scheme and its adopters) from several parties for questionable gain.
http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName This draft has potential.
I disagree on this. It is way too narrowly focused on implementation details of kmod.
What we needed is strict and narrow conventions on kernel-module NEVRs to assure proper interaction with installers.
All the rest is implementation details. Forcing a specific template to me is actionism, because kernel-module rpms are NOT really different from other RPMs, IMO. They are more complex and require strict conventions on their "rpm API", that's all.
/me ducks
Ralf
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> I disagree on this. It is way too narrowly focused on RC> implementation details of kmod.
To some degree I agree with this.
RC> What we needed is strict and narrow conventions on kernel-module RC> NEVRs to assure proper interaction with installers.
Well, it's more than that; we have to ensure proper interaction with the buildsys and there may be restrictions on file locations and such. But beyond those things I agree that a bit of leeway is reasonable.
Of course, this stuff is _hard_, and the templates are a great idea because it allows packagers to just plug the details in. But that's different from saying that the spec MUST conform to that template.
So perhaps we could approach this issue from the other direction: what NEVR convention(s) and file locations are required so that rpm, yum and the like will properly handle the modules, including parallel installs without conflict? What do the spec(s) need to have so that the buildsys can build them for all supported kernel versions and variants?
- J<
On Wed, 2006-08-16 at 23:23 -0500, Jason L Tibbitts III wrote:
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> I disagree on this. It is way too narrowly focused on RC> implementation details of kmod.
To some degree I agree with this.
RC> What we needed is strict and narrow conventions on kernel-module RC> NEVRs to assure proper interaction with installers.
Well, it's more than that; we have to ensure proper interaction with the buildsys and there may be restrictions on file locations and such.
Agreed, like we agree upon "apps go to %{_bindir}", "libs go to %{_libdir}", we need a clear and strict convention on where kernel-modules need to be installed.
How to handle accompanying userspace libs/apps, whether to use split or unified srpms/specs, how many kernel-modules to build simultaneously from one spec are implementation details, each with different pros and cons.
But beyond those things I agree that a bit of leeway is reasonable.
Of course, this stuff is _hard_, and the templates are a great idea because it allows packagers to just plug the details in. But that's different from saying that the spec MUST conform to that template.
Exactly. It's a particular rpm's macroscopic behavior as viewed by the installers that matters.
So perhaps we could approach this issue from the other direction: what NEVR convention(s) and file locations are required so that rpm, yum and the like will properly handle the modules, including parallel installs without conflict? What do the spec(s) need to have so that the buildsys can build them for all supported kernel versions and variants?
Fully agreed, sounds very reasonable to me.
Ralf
On Thu, 2006-08-17 at 06:41 +0200, Ralf Corsepius wrote:
On Wed, 2006-08-16 at 23:23 -0500, Jason L Tibbitts III wrote:
So perhaps we could approach this issue from the other direction: what NEVR convention(s) and file locations are required so that rpm, yum and the like will properly handle the modules, including parallel installs without conflict? What do the spec(s) need to have so that the buildsys can build them for all supported kernel versions and variants?
Fully agreed, sounds very reasonable to me.
I think this pretty much just another way of saying the same thing I posted in https://www.redhat.com/archives/fedora-packaging/2006-August/msg00170.html : focus on the only real technical design issue now, and just reuse the implementation work which is already done as much as possible.
Also, the packaging draft linked to in the above message and the current "standard" doc from which it is derived from should already contain all the above info. Maybe it just needs some restructuring and clarifications in order to prominently specify what part of it is the interface and what is the supporting reference implementation that makes it possible to ship such packages with the current infrastructure.
On Thu, 2006-08-17 at 06:41 +0200, Ralf Corsepius wrote:
Agreed, like we agree upon "apps go to %{_bindir}", "libs go to %{_libdir}", we need a clear and strict convention on where kernel-modules need to be installed.
There is *no need* for kernel modules to go in /lib/modules/kver at all - that's just a convention for built-in kernel modules and I see no reason why we can't have m-i-t pick up modules from other sane locations too. If we can persuade people to use proper MODULE_VERSION()s then we can also sanely decide about which of several versions to use.
Here's one random (not thought it all through) idea:
* Install modules in %{_moduledir}/modulename/kver
Then an RPM provides just the module for whatever kernel versions it wants. But we still need to solve the issue of compatible modules. I quite like the idea of insmod/depmod no longer basing its decisions on data available from depmod using the location of the module, but the compatibility of the module (kABI checks). So we say this:
* m-i-t tries to load %{_moduledir/modulename/this_kver * m-i-t falls back on %{_moduledir/modulename/configured_ordering * m-i-t falls back on /lib/modules/this_kernel
And weak-modules goes byebye because we don't need symlinks any more. We make depmod and insmod/modprobe much more configurable and ship a def. config with some sane options, but allow anyone to have old behavior or more configurable and flexible behavior depending on their config.
What I'm saying is that I'm happy to try out some pretty radical solutions to this problem now that I'm maintaining m-i-t. If we can have a serious discussion about what we *want* from a "perfect system" then we can make it happen properly upstream and get other folks involved - we're not the only people who want to package up modules and agree on standardized locations and mechanisms for choosing updated drivers.
I have spoken to the folks at SuSE/Novell and Ubuntu about driver packaging - though not all the interested parties. I would /really/ like it if some of these non-RPM-specific issues could get solved generally or at least involve the other players who actually use the tools.
I am however /very/ sure that I don't want to try radical stuff ahead of lots of community involvement. In Fedora terms, that means my own personal view is it's way too late to be changing things for FC6 (unless it's decided it's not). I would like us to get somewhere today/this week/whenever towards sensible discussion of ways to fix the problems we have in FC7/etc. and beyond - where IMO we have the time to spend on it.
Jon.
On Thu, Aug 17, 2006 at 04:02:04AM +0200, Ralf Corsepius wrote:
http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName This draft has potential.
I disagree on this. It is way too narrowly focused on implementation details of kmod.
What we needed is strict and narrow conventions on kernel-module NEVRs to assure proper interaction with installers.
All the rest is implementation details. Forcing a specific template to me is actionism, because kernel-module rpms are NOT really different from other RPMs, IMO. They are more complex and require strict conventions on their "rpm API", that's all.
Very nice! :)
Please check out the kmdl interface in the wiki. It is that abstract and flexible that it could even be used with the buggy kmod scheme. It is alse rather free-floating syntax, so you can bolster your rpms just the way you are used to, you just need to make use of a couple macros (like declaring that this package contains kmdls, or a macro that points to the kernel source). No further helper applications/scripts are needed.
The kmdl interface even allows a complete transparent switch to any kabi scheme. E.g. if all of Fedora Extras uses kmdls and a uname-r-in-name, and suddenly the RHEL folks want to reuse all of these kmdls, but with a kabi-version-in-name, they can use the same specfile/src.rpm unchanged! And someone in the future trying to test the kmod scheme bugs, can even also just modify a couple of macros in the kmdl implementation and suddenly the kmdls are named/versioned like kmods!
And even though there is so much flexibility in the kmdl interface scheme it still remains extremely KISS and distro-agnostic.
If you like the kmdl proposal is two-fold
o kmdl interface proposal o kmdl implementation proposal
It's all hidden in the largish wiki text and in the piles of mails.
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote:
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: As I didn't have the time to follow all these discussions and threads, and to have a basis for such an IRC-conference, I would appreciate if Axel and Thorsten could write up a "my proposal at one glance" outline.
I setup an executive summary of the comparison for you and for other people external to the discussion until now who would like to join in on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
and the details remain under
May I suggest comparing kmdls to thl's revised kmods? As it stands there are bugs with the kmod standard that should be addressed so I'd vote +1 for changing the standard. But I'm not understanding the problems with thl's revisions that you are seeing so I'd vote -1 for kmdls and +1 for the revised kmods. A comparison against the revised kmod proposal would help to clarify that portion.
-Toshio
On Wed, Aug 16, 2006 at 09:46:51AM -0700, Toshio Kuratomi wrote:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote:
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: As I didn't have the time to follow all these discussions and threads, and to have a basis for such an IRC-conference, I would appreciate if Axel and Thorsten could write up a "my proposal at one glance" outline.
I setup an executive summary of the comparison for you and for other people external to the discussion until now who would like to join in on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
and the details remain under
May I suggest comparing kmdls to thl's revised kmods?
I already commented to the new suggestion by Thorsten in the appropriate thread. I won't start writing a wiki page for each new suggestion, maybe the people tosing them should invest some time and write wiki docs comparing to kmdls.
On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 09:46:51AM -0700, Toshio Kuratomi wrote:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote:
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: As I didn't have the time to follow all these discussions and threads, and to have a basis for such an IRC-conference, I would appreciate if Axel and Thorsten could write up a "my proposal at one glance" outline.
I setup an executive summary of the comparison for you and for other people external to the discussion until now who would like to join in on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
and the details remain under
May I suggest comparing kmdls to thl's revised kmods?
I already commented to the new suggestion by Thorsten in the appropriate thread. I won't start writing a wiki page for each new suggestion, maybe the people tosing them should invest some time and write wiki docs comparing to kmdls.
I dislike rejecting people, so I looked again at the new proposal ...
Just to make it clear the actual changes wrt kmod are:
o use kabi-version instead of uname-r o disambiguate the file paths of the modules, so modules of different module versions are coinstallable *for the same kernel/kabi*!!!
In fact this scheme is far more broken than the old kmod scheme:
o The 'only-last-kernel-supported' simply becomes 'only-last-kabi-supported'. For Fedora it's the same anyway. So you still have issues with - no (security) updates for old kernels (or kabis) - old kernels/kabis can get their module nuked or effectively disabled.
o Currently there is a file conflicst guard of not having different modules for the same kernel coinstalled. The disambiguation in the file path lifts this safety pin and suddenly we can end up with several different module versions for the same kernel!!!
The kabi stuff is for using modules built for different kernels/kabis, not to have several modules of different versions coinstalled for the same kernel/kabi. We certainly want to have foo-2 kernel modules for kernel/kabi X to replace foo-1 for the same kernel/kabi and not coinstall.
So that's not going to lead anywhere. We'd better stay with kmod scheme than doing that.
And please stop throwing new kernel modules schemes to me :=)
Axel Thimm schrieb:
On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:
o The 'only-last-kernel-supported' simply becomes 'only-last-kabi-supported'. For Fedora it's the same anyway. So you still have issues with
- no (security) updates for old kernels (or kabis)
I was one of those that wanted to build stuff for older kernels in the past. But a lot of people disliked that idea (I can look it up in the archives if someone is interested who that was; most were from RH iirc) and only wanted to support the latest shipped kernel.
If we really want to support older kernels then we need "uname -r" (or kabi, or another identifier) in the %{NAME} *or* a plugin that handles the stuff manually. I think I prefer the "uname -r/kabi" approach in that case.
The question is: do we want to build new kernel modules for old kernels that might have known security problems? Old kernels also get deleted from the servers normally soon and thus aren't all available for the buildsys anymore (only the current one and the one before that are on the servers in the update repo). Building modules for all the kernels we ever shipped would take a lot of build time and space on the servers. A middle way -- build for all kernels still available wold be an compromise if we want to build for more that kernel-current.
Axel, sorry, I'm not sure if I understand that "security" reference above. I understood this currently like this: problem in module -> push out a updated module and the latest kernel gets a fixed module, olders remain unfixed. But hey, older kernels often (not always) had security problems in any case -- that's why there was a new one. Or did I get something wrong here?
- old kernels/kabis can get their module nuked or effectively disabled.
Nope.
o Currently there is a file conflicst guard of not having different modules for the same kernel coinstalled. The disambiguation in the file path lifts this safety pin and suddenly we can end up with several different module versions for the same kernel!!!
Nope, /sbin/weak-modules {cs}hould handle this.
CU thl
On Wednesday 16 August 2006 14:09, Thorsten Leemhuis wrote:
If we really want to support older kernels then we need "uname -r" (or kabi, or another identifier) in the %{NAME} *or* a plugin that handles the stuff manually. I think I prefer the "uname -r/kabi" approach in that case.
Or you can make the package available in the repo, but the end user who is stuck on an old kernel can by hand yum install the specific version they need. Not exactly pretty, but functional, and is just one more part of the pain that is dealing with external modules and pinning to a given kernel.
Thorsten Leemhuis schrieb:
Axel Thimm schrieb:
On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:
- old kernels/kabis can get their module nuked or effectively disabled.
Nope.
Correction: effectively disabled is correct.
CU thl
On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:
o The 'only-last-kernel-supported' simply becomes 'only-last-kabi-supported'. For Fedora it's the same anyway. So you still have issues with
- no (security) updates for old kernels (or kabis)
If we really want to support older kernels then we need "uname -r" (or kabi, or another identifier) in the %{NAME} *or* a plugin that handles the stuff manually. I think I prefer the "uname -r/kabi" approach in that case.
The question is: do we want to build new kernel modules for old kernels that might have known security problems?
Do we want to keep those kernels in the repo? Whatever the policy for kernels it mirrors to the kernel module support. If a kernel is not worth installing, remove it from the repo and the associated kmdls.
Building modules for all the kernels we ever shipped
No, that's not the idea. Only what is considered a sane transition time from kernel to kernel.
Axel, sorry, I'm not sure if I understand that "security" reference above. I understood this currently like this: problem in module -> push out a updated module and the latest kernel gets a fixed module, olders remain unfixed. But hey, older kernels often (not always) had security problems in any case -- that's why there was a new one. Or did I get something wrong here?
In Fedora??? 30% of kernel updates are not security related, and often some kernels are brown bag releases, so many people back up to the previous kernel. Supporting the last kernel is important.
- old kernels/kabis can get their module nuked or effectively disabled.
Nope.
Yep.
o Currently there is a file conflicst guard of not having different modules for the same kernel coinstalled. The disambiguation in the file path lifts this safety pin and suddenly we can end up with several different module versions for the same kernel!!!
Nope, /sbin/weak-modules {cs}hould handle this.
So adding evr semantics to module-init-tools? BTW where is the epoch in your file path suggestion? ... Gotcha! :)
On Wed, 2006-08-16 at 22:36 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
Nope, /sbin/weak-modules {cs}hould handle this.
So adding evr semantics to module-init-tools? BTW where is the epoch in your file path suggestion? ... Gotcha! :)
I'm already adding a conf.d to m-i-t (but still toying with the exact implementation to be figured out over this week) so you can specify the priorities for individual /lib/modules directories. This is actually to solve another problem, which is that sometimes you might want to use kmods to override the built in kernel modules, sometimes not but you might also want to *explicitly* set behavior in the module RPM.
You could (a)buse this to override the ordering of modules if we switched to a new packaging system. Right now, the ordering of directories in our m-i-t is:
* Try /lib/modules/*/updates - if there, the admin did it. * Try /lib/modules/*/extra - if there, it's in a current kmod. * Try /lib/modules/* - if in the kernel, cool. * Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it when looking to find compatible modules on kmod remove/install.
With kabi checking enabled (if you package with kABI deps) then you get for free the compatibility links automatically added/removed on module install/remove so older kernels can use a more recent kmod. You will be able to ultimately instruct module-init-tools to always use the version of a module in weak-updates over the built-in kernel and thereby get a given module to always be available to all compatible installed kernels.
My personal opinion is that it's too late to change kmods drastically in FC6. I think now we're all starting to think about the overall packaging process again that we should have discussions this week about what to do in FC7 and beyond - unless there's a major flaw in kmods (and I don't think we can count any of the existing arguments as sufficient reason to rip out the current status quo at T2 stage) we should leave it for FC6.
Jon.
On Wed, Aug 16, 2006 at 11:04:31PM +0100, Jon Masters wrote:
So adding evr semantics to module-init-tools? BTW where is the epoch in your file path suggestion? ... Gotcha! :)
I'm already adding a conf.d to m-i-t (but still toying with the exact implementation to be figured out over this week) so you can specify the priorities for individual /lib/modules directories. This is actually to solve another problem, which is that sometimes you might want to use kmods to override the built in kernel modules, sometimes not but you might also want to *explicitly* set behavior in the module RPM.
You could (a)buse this to override the ordering of modules if we switched to a new packaging system. Right now, the ordering of directories in our m-i-t is:
- Try /lib/modules/*/updates - if there, the admin did it.
Or any of 67 kmdls from ATrpms.
- Try /lib/modules/*/extra - if there, it's in a current kmod.
- Try /lib/modules/* - if in the kernel, cool.
- Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it
when looking to find compatible modules on kmod remove/install.
The suggestion Thorsten is implying is that you should try under
/lib/modules/*/foo/1/1.2.3/2 /lib/modules/*/foo/1/1.2.3/1 /lib/modules/*/foo/1/1.2.2/1 /lib/modules/*/foo/0/10/1
in that order for several coinstalled versions of foo *for the same kernel* (the folder names are epoch/version/release), and you would have to use rpmvercmp to compare the folder names.
That's a package problem that is being pushed to the wrong domain. For the same kernel (or kabi) the module should have one version installed. Otherwise the argument of having multiple versions of anything, not only kernel modules applies.
With kabi checking enabled (if you package with kABI deps) then you get for free the compatibility links automatically added/removed on module install/remove so older kernels can use a more recent kmod. You will be able to ultimately instruct module-init-tools to always use the version of a module in weak-updates over the built-in kernel and thereby get a given module to always be available to all compatible installed kernels.
The relation is different between what you and Thorsten think. It's many kernel modules *for* the same kernel vs many kernel modules *from different* kernels/kabis.
The kabi solution tries to recycle kernel modules from foreign kernels where possible as given by kabi metrics, it hs nothing to do with kernel module upgrades within the same kernel (as going from foo-1.2.2-1 to foo-1.2.3-1 in the example above). Using the kabi mechanisms for that would be wrong. Just to make it clearer: These pile of kernel modules would share the same kernel abi, e.g. their value for recycling is the same, if foo-1.2.2-1 for kernel X can be recycled, so can foo-1.2.3-1 for the same kernel, so why pick the old package at all?
If the argument is because the newer package might be broken, then the same applies to any other non-kernel related package and we're not going to allow several coinstallations of gcc/glibc/openoffice etc and have the PATH/linker decide on evr semantics.
If the newer pakcage is broken, downgrade to the previous is the typical solution, not coinstall all under the sun :)
My personal opinion is that it's too late to change kmods drastically in FC6.
I agree, my suggestion is not to change, but to dump :)
On Thu, 2006-08-17 at 09:01 +0200, Axel Thimm wrote:
The suggestion Thorsten is implying is that you should try under
/lib/modules/*/foo/1/1.2.3/2 /lib/modules/*/foo/1/1.2.3/1 /lib/modules/*/foo/1/1.2.2/1 /lib/modules/*/foo/0/10/1
in that order for several coinstalled versions of foo *for the same kernel* (the folder names are epoch/version/release), and you would have to use rpmvercmp to compare the folder names.
That's a package problem that is being pushed to the wrong domain. For the same kernel (or kabi) the module should have one version installed. Otherwise the argument of having multiple versions of anything, not only kernel modules applies.
That's a problem. Some people genuinely want to have more than one version of a module installed - I think in the longer run that this would be a good thing to be able to support, though I much prefer using modinfo meta-data to solve it rather than the file location.
We should compel people to use module versions properly in their source code IMO since it's deliberately designed to support what we need from it - and it's trivial enough to warn on build/load of non-kernel provided modules that they don't have good version info inside.
With kabi checking enabled (if you package with kABI deps) then you get for free the compatibility links automatically added/removed on module install/remove so older kernels can use a more recent kmod. You will be able to ultimately instruct module-init-tools to always use the version of a module in weak-updates over the built-in kernel and thereby get a given module to always be available to all compatible installed kernels.
The relation is different between what you and Thorsten think. It's many kernel modules *for* the same kernel vs many kernel modules *from different* kernels/kabis.
*** The following is for explanatory purposes, not part of thread ***
Yeah. We're talking about different things here - I'm just trying to clarify what I've done with the kABI stuff because I didn't really get at this part of the problem before. Let's say this happens (this is more of a RHEL-type problem but *not exclusively* so I mention it here):
* Fedora kernel provides module foo. * Module is upgraded with kmod to bar with different compile options.
Now, if we upgrade the kernel then we might upgrade to a newer and more improved module that happens also to make my root device unavailable because it broke on hardware X. So in that case we want to supply a depmod configuration file along with the kmod files that tells depmod to *always* use the kmod rather than the built-in driver from a newer kernel - i.e. override the weak-updates logic we're using which says that newer kernels always contain better versions of the module.
This isn't the OO problem. OpenOffice doesn't run the risk of breaking your hardware on upgrade and people don't usually want to be able to use different builds of OO from many different locations. With external drivers not provided in Core we are *specifically allowing* people to have several different builds of the same driver in different RPMs.
*** end of off-topic bit ***
If the newer pakcage is broken, downgrade to the previous is the typical solution, not coinstall all under the sun :)
Indeed. Though there's the complication that we'd ideally like to not prevent the system from booting when it's been upgraded remotely. This is not something that is addressed at the moment :-)
My personal opinion is that it's too late to change kmods drastically in FC6.
I agree, my suggestion is not to change, but to dump :)
Dude. We're on T2 right now. In 6 months, there'll be another Fedora and during that time we have plenty of scope to look at this some more. IMHO you haven't shown *compelling* evidence for kmods to be dropped in FC6 but instead have highlighted some issues to be looked at for FC7.
Jon.
On Fri, Aug 18, 2006 at 04:08:49PM +0100, Jon Masters wrote:
On Thu, 2006-08-17 at 09:01 +0200, Axel Thimm wrote:
The suggestion Thorsten is implying is that you should try under
/lib/modules/*/foo/1/1.2.3/2 /lib/modules/*/foo/1/1.2.3/1 /lib/modules/*/foo/1/1.2.2/1 /lib/modules/*/foo/0/10/1
in that order for several coinstalled versions of foo *for the same kernel* (the folder names are epoch/version/release), and you would have to use rpmvercmp to compare the folder names.
That's a package problem that is being pushed to the wrong domain. For the same kernel (or kabi) the module should have one version installed. Otherwise the argument of having multiple versions of anything, not only kernel modules applies.
That's a problem. Some people genuinely want to have more than one version of a module installed - I think in the longer run that this would be a good thing to be able to support, though I much prefer using modinfo meta-data to solve it rather than the file location.
We should compel people to use module versions properly in their source
^^^^^^ That's kernel module authors. Convincing them to use proper versioning is even more difficult than convincing any other upstream author to do the same. Just consider that every module get's its own versioning and some even go back and forth, real-life examples: madwifi and 3w-9xxx.
Before you get them to do a proper versioning, we'll have rpm rewritten.
Furthermore: Even if the versioning of kernel modules was as "good" as other conventional upstream versioning, you still have the same needs for epochs and releases like for conventional packages:
o epoch for when the version seems to go backwards in time in whatever versioning metrics
o release for fixing bugs/patching up kernel modules that won't change their version.
E.g. if I repackage foo-1.2.3-1 with a fix in foo-1.2.3-2, I don't want to see them both installed at the users' systems and hope m-i-t select the proper one.
So when you think about coinstalling modules *for the same kernel/kabi*, you will inevitably both need to introduce full evr semantics on m-i-t level and will have to have rpmvercmp semantics in place. That means coding the evr into the path, since there is no place in the module's metadata *and* the different modules for the same kernel should not overlap.
It is wrong to shift rpm's (or the depsolver's) work to m-i-t. We just lose the overview in keeping the packages managed at one place and the problem still needs to be solved.
code IMO since it's deliberately designed to support what we need from it - and it's trivial enough to warn on build/load of non-kernel provided modules that they don't have good version info inside.
On Wed, Aug 16, 2006 at 11:04:31PM +0100, Jon Masters wrote:
On Wed, 2006-08-16 at 22:36 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
Nope, /sbin/weak-modules {cs}hould handle this.
So adding evr semantics to module-init-tools? BTW where is the epoch in your file path suggestion? ... Gotcha! :)
I'm already adding a conf.d to m-i-t (but still toying with the exact implementation to be figured out over this week) so you can specify the priorities for individual /lib/modules directories. This is actually to solve another problem, which is that sometimes you might want to use kmods to override the built in kernel modules, sometimes not but you might also want to *explicitly* set behavior in the module RPM.
You could (a)buse this to override the ordering of modules if we switched to a new packaging system. Right now, the ordering of directories in our m-i-t is:
- Try /lib/modules/*/updates - if there, the admin did it.
- Try /lib/modules/*/extra - if there, it's in a current kmod.
- Try /lib/modules/* - if in the kernel, cool.
- Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it
when looking to find compatible modules on kmod remove/install.
With kabi checking enabled (if you package with kABI deps) then you get for free the compatibility links automatically added/removed on module install/remove so older kernels can use a more recent kmod. You will be able to ultimately instruct module-init-tools to always use the version of a module in weak-updates over the built-in kernel and thereby get a given module to always be available to all compatible installed kernels.
My personal opinion is that it's too late to change kmods drastically in FC6. I think now we're all starting to think about the overall packaging process again that we should have discussions this week about what to do in FC7 and beyond - unless there's a major flaw in kmods (and I don't think we can count any of the existing arguments as sufficient reason to rip out the current status quo at T2 stage) we should leave it for FC6.
Jon.
-- Jon Masters Phone: +44 7776 131337 Red Hat UK, Ltd. Email: jcm@redhat.com
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
Jon,
Do I understand this correctly?
Grub doesn't know anything about RPM versioning but it knows what kernel to boot because the kernel package / up2date / whatever runs a tool that says make this the default kernel.
I've gleaned so far that the mit tool will be used similarly with kernel module packages to say "use this module as the default in kernel version foo." The user/admin can use the mit tool or whatever to adjust which modules get used with his own packages or configuration management tools as is needed by his requirements.
Jack
On Wed, 2006-08-16 at 19:29 +0200, Axel Thimm wrote:
Just to make it clear the actual changes wrt kmod are:
o use kabi-version instead of uname-r o disambiguate the file paths of the modules, so modules of different module versions are coinstallable *for the same kernel/kabi*!!!
In fact this scheme is far more broken than the old kmod scheme:
o The 'only-last-kernel-supported' simply becomes 'only-last-kabi-supported'. For Fedora it's the same anyway. So you still have issues with
- no (security) updates for old kernels (or kabis)
Okay. I haven't seen anything to contradict this yet, only a conflict over whether this is a problem or not. (If I'm wrong, somebody point me to the archives or restate the rebuttal)
Even if kmdls were accepted, are we planning on having the buildsystem build for multiple kernels?
- old kernels/kabis can get their module nuked or effectively disabled.
How?
Will not get overwritten (which is how I think the term "nuked" has been used in this thread.)
Effectively disabled: What leads you to that conclusion?
o Currently there is a file conflicst guard of not having different modules for the same kernel coinstalled. The disambiguation in the file path lifts this safety pin and suddenly we can end up with several different module versions for the same kernel!!!
But they are not being used. If we treat the kernel modules the same as the kernel itself, then this is expected. It could even be considered desirable: Upgraded modules doesn't work? Re-symlink the old module and you're set.
The kabi stuff is for using modules built for different kernels/kabis, not to have several modules of different versions coinstalled for the same kernel/kabi. We certainly want to have foo-2 kernel modules for kernel/kabi X to replace foo-1 for the same kernel/kabi and not coinstall.
I don't think that's a given. If I installed a new module from source, I'd like the option to coinstall with whatever I had on the system before so I could recover the system if I had to. With packaging it's not as important because I could download the old package and reinstall. Although I think we are removing old packages from the repository. What if the module from January is the last one that worked for me and the next ten do not? (Of course, I may be stuck with an old kernel then, as well... Like I said, I'm not sold either way.)
Also, if I'm rebuilding my kernels from fedora source with some local changes to the kernel.config, a plan that places all external modules into a common directory and then makes symlinks to the relative kernel directories would help me use prebuilt kernel modules.
And please stop throwing new kernel modules schemes to me :=)
The problem is we're here debating 1) Can kmods be saved and 2) if they can't be saved, do we want kmdls to replace them verbatim?
So as you throw problems at the new proposals, people are going to update the proposals to try to fix those problems. In the end we'll all agree that there is an actual problem that no amount of fixing can actually solve, or we'll look at the two proposals and say this pile of hacks is less appealing to me than this one for [insert arbitrary reason here].
-Toshio
On Wed, Aug 16, 2006 at 11:44:56AM -0700, Toshio Kuratomi wrote:
On Wed, 2006-08-16 at 19:29 +0200, Axel Thimm wrote:
o The 'only-last-kernel-supported' simply becomes 'only-last-kabi-supported'. For Fedora it's the same anyway. So you still have issues with
- no (security) updates for old kernels (or kabis)
Okay. I haven't seen anything to contradict this yet, only a conflict over whether this is a problem or not. (If I'm wrong, somebody point me to the archives or restate the rebuttal)
Even if kmdls were accepted, are we planning on having the buildsystem build for multiple kernels?
- old kernels/kabis can get their module nuked or effectively disabled.
How?
Will not get overwritten (which is how I think the term "nuked" has been used in this thread.)
I answered to this on fedora-devel. I also added this to the wiki. But still let's give an example (versions are faked and simplified, I don't want to go hunting them, but the example is bitter real):
ipw2200-1 requires userland package ipw2200-firmware-1
We have two kernels, "a" the old one, "b" the new one. So kmod would deliver something like
ipw2200-kmod-1-a and ipw2200-kmod-1-b
For the two kernels before the module upgrade. Now the following three packages hit the repo
ipw2200-kmod-2-a and ipw2200-kmod-2-b ipw2200-firmware-2
And the kmods require the new firmware.
In the kmdl scheme they would both get installed and the old ones uninstalled (same for the firmware). %post %postun would also perform the proper install/upgrade distinction (another thing kmods fail, you cannot know whether this is an upgrade of install in the specfile, but that's another story).
yum + the current yum plugn support will only try to install/upgrade ipw2200-kmod-2-b and ipw2200-firmware-2, kernel "a" became invisible to the upgrade.
But ipw2200-kmod-1-a has a hard dependency on ipw2200-firmware-1 which is just being upgraded to a new version. Therefore the only way out is to uninstall ipw2200-kmod-1-a.
So you have your old kernel's kmdo nuked.
Effectively disabled: What leads you to that conclusion?
If the dependency was (wrongly) not strict, then the kmod is not nuked, but does not work anymore due to the new firmware => effectively disabled.
o Currently there is a file conflicst guard of not having different modules for the same kernel coinstalled. The disambiguation in the file path lifts this safety pin and suddenly we can end up with several different module versions for the same kernel!!!
But they are not being used. If we treat the kernel modules the same as the kernel itself, then this is expected.
No, you're fallen for the dual nature of kernel modules. They carry a kernel evr and need to be coinstallable wrt that, but they carry their own evr, too, which needs to be in upgrade-mode like all other packages.
Any argument to not do so would propagate to all other packages, too (hey, what if ipw2200-2 is broken, I want a fallback to ipw2200-1 vs hey, what if openoffice-3.0.1 is borken, I want a fallback to openoffice-3.0.0).
And please stop throwing new kernel modules schemes to me :=)
The problem is we're here debating 1) Can kmods be saved and 2) if they can't be saved, do we want kmdls to replace them verbatim?
So as you throw problems at the new proposals, people are going to update the proposals to try to fix those problems. In the end we'll all agree that there is an actual problem that no amount of fixing can actually solve, or we'll look at the two proposals and say this pile of hacks is less appealing to me than this one for [insert arbitrary reason here].
Agreed, but I expect some more homework being done before throwing it out. I usually spend more time in writing an analysis of those hourly proposals than it took the author to think about them.
Axel Thimm schrieb:
[...] I answered to this on fedora-devel. I also added this to the wiki. But still let's give an example (versions are faked and simplified, I don't want to go hunting them, but the example is bitter real):
ipw2200-1 requires userland package ipw2200-firmware-1
We have two kernels, "a" the old one, "b" the new one. So kmod would deliver something like
ipw2200-kmod-1-a and ipw2200-kmod-1-b
For the two kernels before the module upgrade. Now the following three packages hit the repo
ipw2200-kmod-2-a and ipw2200-kmod-2-b ipw2200-firmware-2
And the kmods require the new firmware.
You can package both the old and the new firmware in one package. We did it in livna for ipw2200 because people might still run older Fedora Kernels that requires the new firmware, while the up2date kernel requires the new firmware.
CU thl
On Thu, Aug 17, 2006 at 07:31:59AM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
[...] I answered to this on fedora-devel. I also added this to the wiki. But still let's give an example (versions are faked and simplified, I don't want to go hunting them, but the example is bitter real):
ipw2200-1 requires userland package ipw2200-firmware-1
We have two kernels, "a" the old one, "b" the new one. So kmod would deliver something like
ipw2200-kmod-1-a and ipw2200-kmod-1-b
For the two kernels before the module upgrade. Now the following three packages hit the repo
ipw2200-kmod-2-a and ipw2200-kmod-2-b ipw2200-firmware-2
And the kmods require the new firmware.
You can package both the old and the new firmware in one package. We did it in livna for ipw2200 because people might still run older Fedora Kernels that requires the new firmware, while the up2date kernel requires the new firmware.
What if the package's files shares the same names? Like for instance ipw3945 and ipw3945d (I love real-life examples)?
What if the kmdl is dependend on the exact version of the userland (like nvidia)? Don't we suggest to any decent packager to do have sane versioning in his subpackaging for a good reason?
Bundling packages into one is a bad thing, especially when they are the same package of a different version!!!
That's the problem with pandora's box (see the wiki): You have piles and piles of workarounds/hacks to fix previous bugs of the basic design problems and evey new "fix" is generating more bugs. Maybe it's not pandora's box, but more like a Hydra. ;)
On Wed, Aug 16, 2006 at 10:30:54PM +0200, Axel Thimm wrote:
In the kmdl scheme they would both get installed and the old ones uninstalled (same for the firmware). %post %postun would also perform the proper install/upgrade distinction (another thing kmods fail, you cannot know whether this is an upgrade of install in the specfile, but that's another story).
The argument is rather obvious, but before people ask:
$1 is the number of packages with the same name existing after this rpm operation and is used in scriplets to decide whether this package is a first-time install, an upgrade or a final deletion.
For kmdls this is the number of kmdls for this kernel/kabi, for kmods it for all kernels, therefore the kmod can never know whether it's a first time install/upgrade/deletion for the kernel it's being installed in. E.g. usage of $1 in kmods'scriplets is broken.
On Fri, Aug 18, 2006 at 01:17:22PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 13:40 +0200, Axel Thimm wrote:
usage of $1 in kmods'scriplets is broken.
Why would it be necessary to use it in the first place?
Don't you see any neccessity in having kmdls able to distinguish between being first time installed/upgraded/removed?
I'm not making use of $1 in kmdls, but I can very well think of some use cases:
o storage drivers that need to place themselves in initrd (actually that is a missing feature often reported on qla modules at ATrpms) o creating device drivers for systems w/o dynamic /dev (like RHEL3) o signaling a daemon to either start/reload firmware/stop like the case with ipw3945 & daemon - additionally needs a check whether the operation is for the running kernel. This is also an unfinshed item of ATrpms' kmdls for ipw3945 (there is additionally a racing during installation of kmdls and the daemon and needs to be addressed upstream, but that's off-topic)
You can think of other situations where you do want to know whether this package is upgrade/first-time installed/removed. But to be fair exactly because $1 is not in present use I rated this bug low in the ratings column.
Dropping mechanisms to support a broken scheme just because you don't yet have a current need for that mechanism is wrong.
Hi Warren,
On Tue, Aug 15, 2006 at 08:16:26PM -0400, Warren Togami wrote:
After weeks of discourse on IRC and mailing list discussions, we seem to be unable to make progress toward an amicable agreement. [...] If the packaging committee cannot come to key agreements, then the matter will be escalated to the Fedora Project Board who will make the key decisions.
there was a staged unbundled voting proposal last week:
https://www.redhat.com/archives/fedora-packaging/2006-August/msg00061.html
and there are three people that voted (2 in favor, one against), then Thorsten has strongly voiced concerns about the investment into the old scheme and people stopped voting while the discussions were up again.
I'm in favor of anything that will speed up the voting process or bring in any decision, I think the idea of bringing together all relevant parties is a very good one.
In order to make this meeting manageable, we must limit the number of attendees. Invited are the existing members of the Fedora Packaging Committee, Thorsten Leemhuis and certain Red Hat employees relevant to this discussion. Please talk to me directly if you have been an active contributor to this in the past but are not included in this invitee list.
I would like to suggest Jack Neely and Seth Vital. The latter as a neutral authority on yum and friends to judge on the technical issues raised and the former as the author of the yum support for kmod which IMHO is not working and connot be made to work as well as a big opponent of the new scheme. A working yum is a key point and it would be good to have a fast return of feedback. If they can be convinced that the kmod scheme is unsupportable from yum's POV we're already almost done.
On Wed, 2006-08-16 at 11:20 +0200, Axel Thimm wrote:
I would like to suggest Jack Neely and Seth Vital. The latter as a neutral authority on yum and friends to judge on the technical issues raised and the former as the author of the yum support for kmod which IMHO is not working and connot be made to work as well as a big opponent of the new scheme. A working yum is a key point and it would be good to have a fast return of feedback. If they can be convinced that the kmod scheme is unsupportable from yum's POV we're already almost done.
umm, no. I'm not getting dragged into this.
What the kmod plugin does is what it does and it has worked for me for the cases I have (which is only openafs).
But I'm not going to be a judge of anything. I'm not on the packaging committee, anyway.
-sv
-sv
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote:
It is the decision of me, Max, and Spot, to put a hold on publishing any further kmod modules pending the result the Kernel Module Packaging Standard conference call. Time/date of this call is to be determined, but we are aiming for this Friday, August 18th at a time that is workable for both American EDT and Europe. Perhaps 1PM EDT would work, the usual timeslot of FESCO meetings? Perhaps this timeslot wont work. If you feel it is important to attend but you are unable to make this time, please make it known in this thread.
I'm not able to make a teleconference during business hours (17:00-01:00UTC). I can make an IRC meeting during that time on Friday, though.
I'd say you could tie my vote to Ville's in this case but I see he's not going to be available for the meeting on Friday so I'd rather attend if possible.
-Toshio
packaging@lists.fedoraproject.org
-
Axel Thimm -
Jack Neely -
Jason L Tibbitts III -
Jesse Keating -
Jon Masters -
Ralf Corsepius -
seth vidal -
Thorsten Leemhuis -
Toshio Kuratomi -
Ville Skyttä -
Warren Togami