[Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods

[Thorsten Leemhuis]

Axel Thimm schrieb:
> On Fri, Aug 18, 2006 at 09:00:34PM -0400, Bill Nottingham wrote:
>> Axel Thimm (Axel.Thimm at ATrpms.net) said: 
>>> On Fri, Aug 18, 2006 at 08:24:25PM -0400, seth vidal wrote:
>>>> On Sat, 2006-08-19 at 02:19 +0200, Axel Thimm wrote:
>>>>> o rpm -i behaves properly with file conflicts
>>>>> o yum may for some reason turn of file conflict checking
>>>> There is no code in yum that disables file conflict checking.
>>> I wouldn't think so myself, but Thorsten's report seems to indicate
>>> this.
>>> Is there some other explanation why people don't see file conflicts
>>> under yum?
>> rpm does not properly detect multilib conflicts when packages are
>> installed in the same transaction. This is a RPM bug, and has
>> nothing to do with yum.
>> Bug 190209, if you're curious.
> But the report by Thorsten 

[side note -- I didn't post the report to the list myself -- I noticed
the things in the report on the yesterday and compiled the report
shortly before the meeting and send it only to Spot and Axel in private;
I wanted to extend it slightly (see below) and reread it once more
before posting it to the list]

> did not involve any multilib situation. In
> fact it looked like he used FC5/i386 to test it, check

Yes, I tested it for the report on a i386 machine; but I checked it
before on a x86_64 machine where it worked in the same way.

> https://www.redhat.com/archives/fedora-packaging/2006-August/msg00250.html
> 
> He includes a repeatable setup where yum installs an i686 package
> overwriting another i686 package. I didn't verify the yum setup (but I
> trust Thorsten to have done the right thing),

Well, I'd be glad if someone could reproduce it and check if I did
everything correctly. Computers are stupid sometimes, but in this case I
might have done something wrong.

Albeit: I more and more tend to think I did it correctly because we
(lvn, lvn users, jcmasters in his kABI testing,) would have hit the
"file conflicts on updates" problem often and people would have yelled.
And I go not a single report in livna's bugzilla mention file-conflicts
since we use the kmod scheme.

> I just checked with rpm
> -i alone and that worked as expected, e.g. file conflicts were
> detected and the install aborted.

That's exactly the part that missing in the report -- that works here,
too. See:

> [thl at notebook ~]$ rpm -qa kmod-foo foo-kmod-common
> foo-kmod-common-1.1-1
> kmod-foo-1.1-1.2.6.17_1.2157_FC5
> [thl at notebook ~]$ sudo rpm -ivh /home/thl/tmp/testrepo/kmod-foo-1.1-1.2.6.17_1.2174_FC5.i686.rpm
> Vorbereiten...              ########################################### [100%]
>    1:kmod-foo               ########################################### [100%]
> WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object
> [thl at notebook ~]$ sha1sum /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko
> b9bfed7890b1126a8469291a1a0c19f2c61cdf35  /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko
> [thl at notebook ~]$ sudo rpm -ivh /home/thl/tmp/testrepo/kmod-foo-1.1-2.2.6.17_1.2174_FC5.i686.rpm
> Vorbereiten...              ########################################### [100%]
>    1:kmod-foo               ########################################### [100%]
> WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object
> [thl at notebook ~]$ sha1sum /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko
> f8afd194e3058c40092396d7186d43c239920075  /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko
> [thl at notebook ~]$ rpm -V kmod-foo-1.1-1.2.6.17_1.2174_FC5
> ..5....T    /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko
> [thl at notebook ~]$ rpm -V kmod-foo-1.1-2.2.6.17_1.2174_FC5
> [thl at notebook ~]$

Albeit the rpm output does look a bit confusing:

> [thl at notebook ~]$ rpm -qa kmod-foo foo-kmod-common
> foo-kmod-common-1.1-1
> kmod-foo-1.1-1.2.6.17_1.2174_FC5
> kmod-foo-1.1-1.2.6.17_1.2157_FC5
> kmod-foo-1.1-2.2.6.17_1.2174_FC5
> [thl at notebook ~]$

But that will be clean up sooner or later when the matching kernel is
automatically removed together with the modules.

Am I doing something terribly wrong during testing here? Why does it
fail for Axel, but not for me?

CU
thl