Hi Troy, Marc, All, On Mon, 4 Dec 2006, Troy Dawson wrote: > Marc W. Mengel wrote: > > Troy Dawson wrote: > > > > > kmdl - What Axel Thimm has developed and implemented > > > kernel-module - What we currently are doing, although I believe the idea > > > was originally from livna > > > > It sounds to me like kmdl and kernel-module are similar, modulo the > > actual naming convention -- for a migration path, would it make sense > > to do a merged plugin that accepts either naming convention? That way > > we can migrate from one convention to the other more smoothly(?) 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). > > 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? ... And both the kmdl plugin and the kernel-module one (which is much more out of date, with several kernel flavours present on SL4 and SL5 not being handled) will throw deprecation messages at you when run on SL5. And unlike the merge, which is straightforward to do, getting rid of those will require some knowledge of yum internals. It may or may not be possible to create a plugin that works on both SL4 and SL5, I don't know. 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. > > Marc > > Actually, I had thought of just having both plugin's installed, or at least > available. It shouldn't hurt anything, and allow people to install whichever > one they want. > But as a developer, maintaining both ways is rather painful. Right. And, frankly, needing one plugin is bad enough. Even if one doesn't care about each plugin adding significantly to the amount of work done in YUM's resolve phase (after all, YUM is really fast, isn't it ;-) 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: o Keep doing kernel-modules. It could be kmdls as well, but it makes no difference except in rpm/yum queries. This means updated kernel modules can be provided for obsolete kernels (I think SL has never done it, but that's different from being unable to do it by design), and will be installed automatically. And modules will not be wiped out accidentally, which is the other flaw of kmod as it stands today. o In addition, provide a "stub" kmod (yes...) package for each kernel-module package with a new kernel. The only functional line in the spec would be Requires: kernel-module-xyz-<uname -r> which makes it pull in the actual modules package. No content. Like kmod, this gets the most frequent and important case right, without the need for a plugin: The add-on modules for a new kernel will be installed automatically when this package is updated. No need to touch existing specs (although it seems natural to add the stub kmod package), and no need to maintain python code for an evolving API. It can coexist with "real" kmods, kmdls, and "plain" kernel-modules (for which no stub kmod is provided), on the same system, whether or not plugins for those are installed. It will work with any (future) package update tool, out of the box. If there'd ever be a working plugin for kmods (the one in CVS will have very useful features - like preventing kernel upgrades from happening if modules are missing - if it ever gets finished), or corresponding functionality is added to rpm and/or yum, SL would benefit immediately, without the need to change anything. 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... Stephan -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany