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.

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


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