[Fedora-packaging] kmdl proposal and kmod flaws

[Jack Neely]

On Wed, Aug 09, 2006 at 12:29:08AM +0300, Ville Skyttä wrote:
> On Tue, 2006-08-08 at 14:04 -0500, Tom 'spot' Callaway wrote:
> > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote:
> > > I've created a wiki page outlining the kmdl design as well as showing
> > > the flaws of the current kernel module scheme ("kmod"):
> > > 
> > > 	  http://fedoraproject.org/wiki/AxelThimm/kmdls
> 
> One thing completely missing from that is debuginfo packages.
> 
> The NEVR of the debuginfo package is derived from the name of the
> *source* package, which means overlaps/unshippability of debuginfo
> between builds unless 1) the source package's NEVR changes on every
> rebuild, *including* just rebuilding it for a newer kernel using
> different rpmbuild flags or whatever, or 2) the module packages
> implement their own debuginfo package creation.
> https://bugzilla.redhat.com/113276
> 
> > The reason that third party repositories such as ATrpms have
> > been so successful is because things just work.
> 
> Things certainly haven't "just work"ed without special user education
> and making POLA violations a standard practice.  Dunno about the current
> state of affairs with using that scheme, but I've seen the bug reports
> elsewhere in the past.  Before depsolvers are adapted to do "the right
> thing", their users need to remember to manually pull in module package
> updates when a new kernel is installed.  Granted, with the suggested
> scheme, they *can* do that without interference from other module
> packages in more situations than with the current one, ditto with the
> rpm CLI.
> 
> > I now believe that the benefits of overloading the name with kver
> > outweigh any pain it causes
> 
> I have no doubts that it can be made to work (and there is still some
> work to do, eg. debuginfo, depsolvers), but I'm still not convinced that
> it's worth the trouble.  But that's moot if consensus says otherwise and
> there's competent manpower available to do the work.
> 

I've spent quite a bit of time working on a Yum plugin to add the proper
functionality to Yum.  In fact I spent part of today adding some
features that Thorsten had requested.  My goal was to have decent
support in FC6 for kernel modules.  The freeze is about a month away.

I will veto Axel's current plugin as it uses regular expressions to
parse the name of the package.  I've seen some fun kernel versions and
parsing that out of the name is just asking for corner cases.
This information needs to be pulled from what the package provides or
requires.

Most of my hesitation regarding the uname-r in name scheme is because
this was fully discussed before and we decided on something different.
FESCo ratified it and we were going to be able to support in in FC6 and
RHEL 5.

There is another important trade off here.  Right now
up2date/yum/whatever is able to suck down upgraded kernel modules just
like upgrades to a new kernel.  This works without modifications to the
depresolvers because the package name is always the same.  With the
uname-r in name scheme we are now dependent on some other additional
magic to pull down the new kernel modules for the new kernel everyone
got 3 days ago.  My shop depends on OpenAFS.  AFS issues are a complete
show stopper.  I manage well over 1,300 servers/workstations.  Now
instead of writing code to make my job easier I have to write code to
keep my work load at its current level.  

Jack

-- 
Jack Neely <jjneely at ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89