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 __________________________________________________