On Tue, Jan 23, 2007 at 11:24:15AM -0600, Troy Dawson wrote:
> Hi All,
> I'm sorry I let this thread die before there was a resolution.  I was 
> busy there for a bit, and then just never got back to it.  I appologize 
> for that.
> 
> From the sounds of things it sounds like we should do both a 
> kernel-module and a kdm plugin.  And if possible, have both in the same 
> plugin, since there will be alot of redundant code.
> 
> The idea's of using a stub sounds interesting, but since that seems like 
> it's going to need some development and testing time, how about we stay 
> with what is already developed, at least for now.

I've already checked with the stub idea and I think it is great. You
don't need any plugins, so yum/apt/smart/<more depsolvers here> work
right out of the box.

Also in the case of kmdl one doesn't even need to alter the specfiles,
as this can be implemented as part of the %kmdl macro. E.g. %kmdl foo
declares both the foo-kmdl-`uname -r` package, as well as the kernel
series stub package.

I've given it a lot of thought and it looks more than promising. I'll
also cut on the size of kmdl specfiles more, by pulling some standard
redundant parts into the %kmdl invocation. It would have to be called
%kmdl2 or similar since that does alter the kmdl specfile API.

Needless to say: I'd vote for going fully kmdls ;)

> Troy
> 
> Axel Thimm wrote:
> >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