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

Axel Thimm Axel.Thimm at ATrpms.net
Sat Aug 19 00:19:25 UTC 2006


In the session today it was stated that rpm -i on packages of the same
name does not check file conflicts. Since many people reported that
this was the case I thought I missed the latest in rpm bug regression.
But that's not the case, at least not on FC5:

Cut and paste the two almost identical specfiles at the end of this
mail and rpmbuild -bb them. You will get

	      test-1-1.i386.rpm  test-2-1.i386.rpm

Both containing just /tmp/delmex with contents "XXX" and "YYY". Now
try:

| # rpm -ihv test-1-1.i386.rpm
| Preparing...                ########################################### [100%]
|    1:test                   ########################################### [100%]
| # rpm -Vp test-2-1.i386.rpm
| ..5....TC   /tmp/delmex
| # rpm -ihv test-2-1.i386.rpm
| Preparing...                ########################################### [100%]
|         file /tmp/delmex from install of test-2-1 conflicts with file from package test-1-1

So rpm is not to blame it properly catches the file conflict.

Now why do other people claim otherwise, and does it make any
difference in the context we we discussing it?  It may seem to "work"
for other people because:

a) either the contents of the test packages they tried were identical,
   e.g. rpm checks the md5sum of the files, it does not care about
   package names when it checks for file conflicts,

b) or (according to a report from Thorsten) it may be yum that
   effectively uses rpm -i --replacefiles on the transaction. A yum
   expert could confirm the latter or not. at least it looks like
   Thorsten only used yum for testing and not rpm -i.

Does it matter at all?

In the scope of the discussion not really, it is probably making
things worse. The file conflict situation only comes up when some
depsolver, be it a human or yum/etc. decides to coinstall a package
not meant for coinstallation. In this scope it is for example a
release bump in a module for the same kernel. Accidentially using rpm
-i on it would

- either create the file conflict, in that sense the file conflict is
  a *guardian institution*

- or if the --replacefiles flag is turned on, *WILL OVERWRITE* the old
  module, maybe even just partially, since the new module package may
  have a different set of ko files. Even funnier effects may happen if
  the now overwritten old module still in the rpmdb is tried to be
  removed. But we're already in a broken state, so who cares whether
  it can be worse.

In a nutshell:

o rpm -i behaves properly with file conflicts
o yum may for some reason turn of file conflict checking
o The file conflict situation is actually WELCOME, as it is a SAFETY
  precaution to not messing up thing (either by hand or automatically)

And this has absolutely nothing to do with whether rpm -i can be
applied to kmods, because

1) obviously rpm -i wasn't tested, or wasn't tested with differing
   contents in the rpm
2) rpm -i SHOULD not be used on kmods when a kmod is already installed
   for this kernel.
3) If you still go ahead and use rpm -i on a kmod while a kmod is
   already installed you get the file conflict as stated.
4) If you do the same with yum the new kmod overwrites the old one w/o
   any warning

The desired operation that the kmod should do is only possible in the
fedorakmod.py code: Don't touch kmods of other kernels, and upgrade
kmods of the target kernel.

      Still: USAGE OF RPM CLI (-U/-i) IS NOT WORKING WITH KMOD

And for all the non-believing Thomases (as in Thomas the evangelist)
out there, the everlasting example wrapped as a RHCE question to make
it more interesting:

  kernel-2.6.17 has kmod-foo-1.2.3_2.6.17 installed
  kernel-2.6.18 has kmod-foo-1.2.3_2.6.18 installed

  kmod-foo-6.6.6_2.6.18 for kernel 2.6.18 appears. How do you install it
  in the system above with a single rpm call (e.g. w/o removing the
  modules before reinstalling them) and w/o disrupting the old kernel's
  foo support?

  a) rpm -i
  b) rpm -U
  c) not at all

Usage of rpm -i/rpm -U on kmod scheme is broken, end of story. I'm
still shocked it suddenly was defined working a couple hours earlier
today.

=======================================================================

test.spec
=========
Summary: test
Name: test
Version: 1
Release: 1
License: l
Group: g
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root

%description
x

%install
mkdir -p %{buildroot}/tmp
echo XXX > %{buildroot}/tmp/delmex

%files
%defattr(-,root,root,-)
/tmp/delmex

test2.spec
==========
Summary: test
Name: test
Version: 2
Release: 1
License: l
Group: g
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root

%description
x

%install
mkdir -p %{buildroot}/tmp
echo YYY > %{buildroot}/tmp/delmex

%files
%defattr(-,root,root,-)
/tmp/delmex
-- 
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://lists.fedoraproject.org/pipermail/packaging/attachments/20060819/e019f920/attachment.bin 


More information about the packaging mailing list