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