On Mon, Dec 04, 2006 at 11:51:10PM +0100, Stephan Wiesand wrote:
> 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).

I'm welcoming patches, although the missing PAE and xen kernel
flavours are trivial and not worth spenifn time on patching it. ;)

> > > 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? ...

Yes, on FC6. There are some known troubles with FC6's yum, and fixing
these will break the kmdl pluging for FC5 and RHEL4 downwards. Maybe
one can keep two plugins, one for SL4 (3?) and one for SL5.

> 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.

That's why it makes sense to unite forces. ATrpms will have to
maintain the kmdl plugin. If SL uses the same semantics, kmdl macros,
plugins etc can be comaintained.

> 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:

> 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...

No, I think the idea is basically OK, and it has been discussed in
similar scope on fedora-packaging and/or atrpms-devel, but not as
clear as in your proposal. It does have a couple of issues, though:

- You will need a mechanism for supporting other than the "blessed"
  kernel, so you still can't skip the plugins (but the idea is to make
  the default procedure easier, granted).

- And you will get an issue with custom kernels like the centosplus or
  ATrpms' swsuspend2 kernel series which again ambiguate the idea of a
  "latest" kernel, e.g. you would need a stub package for each of
  them. But that's not what every user does, so it affects only a
  smaller target group.

- currently userland parts depend on virtual hooks to the kmdls (or
  kernel-modules). For using the suggested mechanism, you would
  effectively devirtualize this dependency, e.g. the userland packages
  depend on the stub which depends on the true kmdls. It would require
  users to install the "blessed" kernel, e.g. the latest even though
  they only want another kernel or another kernel series.

Still the idea is not bad, the issues only show that it needs to be an
opt-in for serving 90% of the users' demands, e.g. it should not be a
required component, but if a user decides to use the stub package he
should be able to always stay updated w/o a plugin in any depsolver.

Let's try to get this going. :)
-- 
Axel.Thimm at ATrpms.net