Axel Thimm schrieb:
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.
Well, you said "Suppose you have two active kernels (say 2.6.16 and
2.6.17 or xen0 and non-xen0 etc.) [...]e.g. at least one kernel stay w/o
any kmdl[...]" above -- and xen0 and non-xen0 work fine with the scheme,
both have a module.
> $ 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.
Well, seems to be a bug for you. Okay, noted. I'd consider is as an
minor annoyance. And it seems Jack Neely is working on getting it fixed.
You don't want to only support the
rpm-latest kernel,
To support only the latest kernel was a decided early in the kmod
discussion. That might have influenced the kmod standard.
BTW, when we initially discussed the kmod standard there was also (IIRC)
a strong resistance from multiple important and well known people at
redhat against overloading %{NAME} with the output of "uname -r". I
doubt that option changed. Spot? Jeremy? f13?
[...]
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?
Nobody reported a bug yet. And the nvidia driver is a good example: we
even have explicit "Obsoletes" in the spec to make sure old modules
always get removed because nvidia-1.2.3 only works with
kmod-nvidia-1.2.3, but not with kmod-nvidia-1.2.2
> 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).
And it also needs special support in depsolvers so you get all
kernel-modules together with a kernel update.
And you need to maintain a lot of obsoletes to get old kmods removed
that are incompatible with the updated userland packages. Or you need to
build kmods for each and every kernel that ever shipped -- that would
take to long (and they are often not available anymore).
So, do we at least agree that the current kernel modules scheme
breaks
on rpm CLI level?
No.
Neither rpm -i, nor rpm -U could get you out of the
above (typical!) situation.
I don't consider it a big problem.
CU
thl