[Fedora-packaging] Re: atrpms kernel modules

[Axel Thimm]

On Thu, Jul 20, 2006 at 05:58:02PM +0200, Thorsten Leemhuis wrote:
> Axel Thimm schrieb:
> > On Wed, Jul 19, 2006 at 07:40:38PM +0200, Thorsten Leemhuis wrote:
> >> Axel Thimm schrieb:
> >>> rpm for one can't cope with it. Suppose you have two active kernels
> >>> (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have
> >>> foo-kmdl for both in version 1. Now foo-kmdl in version 2 is
> >>> released. Both rpm -i (coinstall, no replacement of of foo-kmdl for
> >>> the same kernel) and rpm -U (remove all foo-kmdl but the highest one,
> >>> e.g. at least one kernel stay w/o any kmdl) won't work.
> >> Well, yes, coinstall will fail because this would result in a file
> >> conflict. But rpm -U works fine (but removes the older version) with the
> >> current Extras kmod scheme and "yum install foo" AFAICS works fine, too.
> > No, rpm -U would remove both kernel modules from both kernels and only
> > install the selected kernel module, you end up with one kernel losing
> > the kernel module w/o replacement.
> > 
> > rpm -U will always leave only one kernel module package behind unless
> > these packages are disambiguated in their name by extending the name
> > to contain the kernel's uname -r.
> 
> I don't want to reply to the other aspects of this mail -- I don't think
> it makes to much sense now and prefer to wait for the docs from Axel.
> But it seems we talked pass each other in above section so I'll try to
> give an example to show the behavior with the current Extras scheme
> (note this is not tested, only written down how it works afaik):

No, I don't think we talked past each other, you are giving a perfect
example outlining the design bug of any non-uname-r-in-name scheme.

> $ rpm -q kernel
> kernel-2.6.17-1.2145_FC5
> kernel-2.6.17-1.2157_FC5
> kernel-smp-2.6.17-1.2157_FC5
> $ rpm -qa kmod-ntfs*
> kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5
> kmod-ntfs-2.1.27-1.2.6.17_1.2157_FC5
> kmod-ntfs-smp-2.1.27-1.2.6.17_1.2157_FC5
> 
> kmod-ntfs{,-smp,xen0,...}-2.1.27-2.2.6.17_1.2157_FC5 show up in the repo
> and user runs yum update. After that:
> 
> $ rpm -qa kmod-ntfs*
> kmod-ntfs-2.1.27-2.2.6.17_1.2157_FC5
> kmod-ntfs-smp-2.1.27-2.2.6.17_1.2157_FC5
> 
> E.g. yes, kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 got removed.

Which is the bug in the scheme. You don't want to only support the
rpm-latest kernel, just as you want to give freedom to the users to
have multiple kernel rpms installed (of different versions) as it too
often happens that the new kernel may not work on their systems.

E.g. every policy you follow for the kernel rpms themselves needs to
be followed for the per-kernel installed kernel modules. So the kernel
module of the "old" kernels need to stay untouched, by rpm and any
higher-level packaging manager/depsolver.

Ignoring the bug on rpm CLI level and trying to fix all depsolvers out
there is IMO wrong. rpm CLI needs to do a reasonable operation when
presented these kernel module packages, not "accidentally" nuke away
parts for the working previous (and perhaps already running)
kernel.

The next horror scenario is to decide to keep this scheme and start
working around it in each depsolver leaving some out like for example
the increasing in popularity smart depsolver. smart upgrade would then
happily nuke your display driver kernel module of the running kernel!
Same for apt and up2date.

In fact the above is not to be layed in the future, but it's the
current situation w/ for example livna, or not? Aren't there any livna
reports that they lost their nvidia driver for old kernels while
updateing their system?

> No, both the up and the smp-kernel still have their modules.

And the reason is kernel flavour disambiguation through the name. Add
the kernel's version to the name and you'll fix the bug mentioned
above. And suddenly it's a uname-r-in-name scheme again and very close
to kmdl systems (so let's pick that design and be all happy).

So, do we at least agree that the current kernel modules scheme breaks
on rpm CLI level? Neither rpm -i, nor rpm -U could get you out of the
above (typical!) situation.
-- 
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/20060721/00820df5/attachment.sig>