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
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?
Note that according to Thorsten's report this is w/o any special kmod/kmdls or other plugins (or only installn, but that shouldn't matter).
Axel Thimm (Axel.Thimm@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.
Bill
On Fri, Aug 18, 2006 at 09:00:34PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@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 did not involve any multilib situation. In fact it looked like he used FC5/i386 to test it, check
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), I just checked with rpm -i alone and that worked as expected, e.g. file conflicts were detected and the install aborted.
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 09:00:34PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@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@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@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@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@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@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@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@notebook ~]$ rpm -V kmod-foo-1.1-2.2.6.17_1.2174_FC5 [thl@notebook ~]$
Albeit the rpm output does look a bit confusing:
[thl@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@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
On Sat, Aug 19, 2006 at 02:06:05PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 09:00:34PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@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?
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.
Wow, that means that if it indeed does not yell, that people w/o fedorakmod.py are happily overwriting their previous kernel modules?
For example with the change of the name of the openafs ko module, the users had two modules simultaneously installed praying for the userland to modprobe the correct name ...
Coinstallation of kernel modules of different module evr for the same kernel is a bug as explained before. File conflicts are guardians, and w/o you (partly) overwrite your old module.
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@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@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@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@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@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@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@notebook ~]$ rpm -V kmod-foo-1.1-2.2.6.17_1.2174_FC5 [thl@notebook ~]$
Am I doing something terribly wrong during testing here? Why does it fail for Axel, but not for me?
I would start with simpler examples like the two minimal specfiles I posted. If you still don't get file conflicts something is really off here (I have a vanilla FC5/i386, e.g. rpm-4.4.2-15.2), maybe you're tuning rpm over global macros?. If you do get file conflicts then it's part of the kmod specfile - start adding parts that you suspect may confuse rpm enough to not report the conflict, so you know what part of the specfile did it.
Axel,
There's a fundamental misunderstanding here about using rpm -i. You claim that it does not function for kmods. Most of us consider your examples for this an upgrade path rather than an install path.
We consider rpm -i only useful for the install path where there are no other kernel modules of that name installed on the system. So, when no previous versions of a specific kernel module are installed and we use rpm -i to install one, there are no file conflicts. The package is installed correctly.
Other cases are considered upgrade paths and we agree that rpm -U does not give the desired behavior. rpm -i should not be used for an upgrade path as it does not work for any package at all.
Jack
On Sat, Aug 19, 2006 at 06:25:30PM -0400, Jack Neely wrote:
There's a fundamental misunderstanding here about using rpm -i. You claim that it does not function for kmods. Most of us consider your examples for this an upgrade path rather than an install path.
The key point is that neither -U, nor -i, nor any other rpm cli transaction can support kmods.
Restricting the starting environment does not count. In this case firefox and any other conventional package can also be installed with -i.
So whether you want to give "rpm -i" a name or not, doesn't matter. I call it neither upgarde, nor (co)install, I just make the technical and correct observation that "rpm -i" does not work - as "rpm -U" does not work.
And since both do not work rpm cli operation with kmods is impossible which is the final aspect here.
Please note that restricting the starting environment (e.g. kmod free setup) does really not count as an argument that rpm -i/-U works.
Jack Neely wrote:
Axel,
There's a fundamental misunderstanding here about using rpm -i. You claim that it does not function for kmods. Most of us consider your examples for this an upgrade path rather than an install path.
...
Other cases are considered upgrade paths and we agree that rpm -U does not give the desired behavior. rpm -i should not be used for an upgrade path as it does not work for any package at all.
IMO, seems to be an argument for using the uname-r mechanism, so no such problems, misunderstandings occur.
-- Rex
Jack Neely wrote:
We consider rpm -i only useful for the install path where there are no other kernel modules of that name installed on the system. So, when no previous versions of a specific kernel module are installed and we use rpm -i to install one, there are no file conflicts. The package is installed correctly.
That may be the typical usage, but there's nothing about RPM that mandates this. Different versions of the same package can happily coexist as long as their files don't conflict.
For an example of this, look no further than the practice of keeping older kernels around. In this case, the "upgrade" is performed with rpm -i (or its API equivalent); if rpm -U were used, the old kernel would be automatically removed.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Bill Nottingham -
Ian Pilcher -
Jack Neely -
Rex Dieter -
seth vidal -
Thorsten Leemhuis