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