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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
