[Fedora-packaging] blocking kmdl adoption at all costs? (was: atrpms kernel modules)

Axel Thimm Axel.Thimm at ATrpms.net
Tue Aug 8 05:53:19 UTC 2006


On Tue, Aug 08, 2006 at 07:40:51AM +0200, Thorsten Leemhuis wrote:
> Axel Thimm schrieb:
> >On Mon, Aug 07, 2006 at 06:22:52PM +0200, Thorsten Leemhuis wrote:
> >>Axel Thimm schrieb:
> >>>On Sun, Jul 30, 2006 at 06:04:34PM +0200, Thorsten Leemhuis wrote:
> >>>>Toshio Kuratomi schrieb:
> >>>>>Apologies for posting into the wrong subthread of this monster, I
> >>>>>already deleted the relevant mail.
> >>>>>
> >>>>>If one of the major issues with the current kmod spec is that neither
> >>>>>rpm -U nor rpm -i work correctly, shouldn't that be corrected?  If the
> >>>>>module could install into something like this:
> >>>>>  /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko
> >>>>>
> >>>>>instead of:
> >>>>>  /lib/modules/KERNELVER/extra/MODULE/MODULE.ko
> >>>>>
> >>>>>wouldn't that bring the behaviour of kmods inline with that of the
> >>>>>kernel?  (Use rpm -i for normal operations, rpm -U if you don't believe
> >>>>>in Murphy).
> >>>>I like that idea -- especially when combined with the the kabi stuff.
> >>>>Yes, someone still could run "rpm -Uvh" and would loose older kmods, but
> >>>>yum and apt would do the right thing.
> >>>Why would suddenly yum/apt work better?
> >>Because
> >>
> >>/lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko
> >>
> >>avoids that there are ever file conflicts between packages so yum will
> >>always be able to install the new module (just like the kernel -- you
> >>can of course still do rpm -Uvh manually, but I don't care because
> >>that's possible with the kernel, too).
> >
> >I understand, you push the problem from rpm/yum to module-init-tools,
> >e.g. now /sbin/depmod needs to understand rpmvercmp to decide which
> >MODULE-VERSION-RELEASE is newer?
> 
> Well, if we use the kerneldrivers stuff from jcm then
> /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko
> seems like the better place for modules than
> /lib/modules/KERNELVER/extra/MODULE/MODULE.ko
> because the latter path might be confusing when KERNELVER was already 
> deinstalled.

I agree, but still something needs to manage the evr (where epoch is
missing in the above path BTW) comparison of modules per kernel.

> >The issue is still there, just not where it belong, in rpm and yum. It
> >is now at module-init-tools level and suddenly /sbin/depmod would need
> >to understand rpm ordering rules.
> 
> The kerneldrivers stuff will handle that in any case afaics. The 
> question is: do we want to use it. There are also other open question if 
> we want to use it, e.g.
> - when does a kmod get removed?
> - do we need to drop the hard dep on the kernel
> 
> >I don't think that's an improvement :)
> 
> I didn't try it out yet. Maybe it's an improvement, maybe not.

*Something* in the system needs to be able to compare different evrs
of "MODULE-VERSION-RELEASE" and decide on *removing* the old
module. It really *needs removal* and not simple overriding because
the new and old kernel module package's contents may differ in the
number/names of carried kernel module files.

Even if removing would not be needed and we could live with
module-init-tools doing some magic you would still have to push the
rpmvercmp logic to module-init-tools which upstream will not
accept. And we don't gain anything: The problem must still be solved,
it just looks like being out of sight.

So pushing this problem out of rpm's and yum's scope is very wrong and
only creates more problems. This is not against the actual location of
kernel module files. For the kabi forward-compatibility stuff thinking
about new locations is OK, but it will not solve the issues we're
talking about. It's realy purely orthogonal.

<rant>
Did I mention that resitance is futile? This is the umpteenth attempt
to find something to block kmdl adoption, that I need to argue
against. If I would had put that energy into something else I would
probably had solved the TOE by now.

Possibly my attempts to get a sane kernel module packaging scheme is
futile ...
</rant>
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060808/251993e2/attachment.sig>


More information about the Fedora-packaging mailing list