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