Hi Troy, Marc, All,

On Mon, 4 Dec 2006, Troy Dawson wrote:

> Marc W. Mengel wrote:
> > Troy Dawson wrote:
> > 
> > > kmdl - What Axel Thimm has developed and implemented
> > > kernel-module - What we currently are doing, although I believe the idea
> > > was originally from livna
> > 
> > It sounds to me like kmdl and kernel-module are similar, modulo the
> > actual naming convention -- for a migration path, would it make sense
> > to do a merged plugin that accepts either naming convention?  That way
> > we can migrate from one convention to the other more smoothly(?)

Yes, that seems feasible. I looked into the code, and I think the kmdl 
plugin could be extended to deal with kernel-modules as well quite 
easily. It uses a regular expression to identify kmdls, something like
(.*)-kmdl-.*, and by duplicating a few lines of code (the whole thing is 
some 100 lines) in two subs, using a different regex - probably something
like kernel-module-(.*)-[^-]+-[^-+], it should work for both kmdls and 
kernel-modules.

Once at it, one could also add the missing kernel flavour (PAE) to the 
list coded into the plugin (I think I fetched the most recent version, 
from the EL5 ATRPMS repository, and it's missing).

> > Or are there more devilish details there than I've gleaned from the
> > discussion so far?

A message on scientific-linux-users today indicates that there may 
be a problem with yumex if the kmdl plugin is installed. That's 
unconfirmed, of course. And on SL5, we'll have pirut and may not need 
yumex anymore. But then, has the kmdl plugin been tested together with 
pirut? Pup? ...

And both the kmdl plugin and the kernel-module one (which is much 
more out of date, with several kernel flavours present on SL4 and SL5 not 
being handled) will throw deprecation messages at you when run on SL5. And 
unlike the merge, which is straightforward to do, getting rid of those 
will require some knowledge of yum internals. It may or may not be 
possible to create a plugin that works on both SL4 and SL5, I don't know.

Yum is a moving target, as are kernel flavours. Maintaining a plugin is 
a significant burden. And even more so if one considers possible 
interaction with other tools.

> > Marc
> 
> Actually, I had thought of just having both plugin's installed, or at least
> available.  It shouldn't hurt anything, and allow people to install whichever
> one they want.
> But as a developer, maintaining both ways is rather painful.

Right. And, frankly, needing one plugin is bad enough. Even if one doesn't 
care about each plugin adding significantly to the amount of work done in 
YUM's resolve phase (after all, YUM is really fast, isn't it ;-)


So I've been pondering the thought of getting by without plugins, while 
having the best of kmod/kmdl/kernel-module, without their drawbacks, and 
without much overhead. And maybe it's possible, although I admit
it seems a little weird at first glance:

 o Keep doing kernel-modules. It could be kmdls as well, but it makes no
   difference except in rpm/yum queries.

   This means updated kernel modules can be provided for obsolete kernels
   (I think SL has never done it, but that's different from being
   unable to do it by design), and will be installed automatically.

   And modules will not be wiped out accidentally, which is the other flaw
   of kmod as it stands today.

 o In addition, provide a "stub" kmod (yes...) package for each 
   kernel-module package with a new kernel. The only functional line in
   the spec would be
     Requires: kernel-module-xyz-<uname -r>
   which makes it pull in the actual modules package. No content.

   Like kmod, this gets the most frequent and important case right,
   without the need for a plugin: The add-on modules for a new kernel
   will be installed automatically when this package is updated.

No need to touch existing specs (although it seems natural to add the 
stub kmod package), and no need to maintain python code for an evolving 
API.

It can coexist with "real" kmods, kmdls, and "plain" kernel-modules (for 
which no stub kmod is provided), on the same system, whether or not 
plugins for those are installed.

It will work with any (future) package update tool, out of the box.

If there'd ever be a working plugin for kmods (the one in CVS will have 
very useful features - like preventing kernel upgrades from happening 
if modules are missing - if it ever gets finished), or corresponding 
functionality is added to rpm and/or yum, SL would benefit immediately,
without the need to change anything.

All at the cost of a trivial stub kmod per kernel-module.


I guess someone's going to tell me now why this idea is crazy...

  Stephan

-- 
Stephan Wiesand
  DESY - DV -
  Platanenallee 6
  15738 Zeuthen, Germany