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

I have one question about the stub package.
If the stub has
   Requires: foo-kmdl-`uname -r`
What happens when you update your kernel when you already have the stub 
installed?
`uname -r` = 2.6.19-10.0.2
yum update brings in kernel 2.6.19-10.0.3
Unless you have a plugin, then it's not going to get the new kdml
Or am I missing something?

Troy


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