Hi Stephan,
No flame war at all ... at least I hope not.

With S.L. 5 we will move to the new way of doing kernel modules, with is 
the "kmod" scheme.
This scheme is really the correct way of doing things, since it is 
integrated all the way into rpm ... or at least it's macro's.  It is 
also the way that RedHat will be doing their kernel modules (thank 
goodness), so we won't have two ways of doing kernel modules in S.L. 5.

So if this is the correct way to do things, why isn't it in S.L. 4.x and 
  3.0.x?
Reason One: Stability.
We don't want to do major changes to yum in the mature releases.  That's 
why S.L. 3.0.x is still at yum 2.0.x, and why S.L. 4.x is still at yum 
2.4.x.
Changing the way we do kernel modules would really be a drastic change 
for our users.

Reason Two: rpm
Axel might know the details about this better, so if I'm wrong, I apologize.
Part of the magic of the "kmod" way is in rpm itself.  I don't know if 
it's the macro's, or built into the code, but the newer rpm knows what 
to do with objects marked as kernel modules.
If you think we're stubborn about upgrading to the next release of yum, 
just try to ask us to update to the next release of rpm.  The answer is 
no, that's not happening, at least not in the main release.

I'm actually glad you brought this up, because switching over to the 
"kmod" way will require re-doing the various kernel module rpm's that 
have been written.
As I look at the few that I have, this doesn't look like a major 
re-write, just some different settings in the spec header section, 
and/or the individual package header sections.

Does anyone have any reasons other than having to redo the kernel-header 
rpm's, why we shouldn't move to the "kmod" way of doing things with S.L. 5?

Troy

Stephan Wiesand wrote:
> Hi Enrico, Troy, All,
> 
...snip...
> 
> But regarding SL5, there's one design question to be answered:
> 
> Should/will SL stay with the "kernel-module" scheme for kernel modules, or 
> adopt the "kmod" scheme that's in use in FC6 and EL5beta, and will most 
> likely be in EL5 GA? I don't have too strong an opinion on this issue
> (both have their pros and cons), but it would be nice to have the giants'
> ruling on it...
> 
> Hope I haven't started a flame war now,
> 	Stephan
> 
...snip...

-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________