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? 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. I don't think that's an improvement :) -- Axel.Thimm at ATrpms.net
Attachment:
pgpHPbSy65PUS.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
