Warning: long.
Summary:
(1) yum isn't doing what I want with respect to updating packages that
come in i386 and x86_64 architectures.
(2) one example looks like a bug
Background:
I'm trying to install FC6 for x86_64 on my notebook (this is not going
smoothly, but that is a topic for another time).
I have an NFS server with a copy of all the updated RPMs.
I'm trying to apply these updates.
In the past, I've applied updates from the NFS server by doing:
yum localupdate *.rpm
(In the more distant past, I used
rpm -Fv *.rpm
but that didn't work well when updated packages had new dependencies.)
Right now, this yum command is failing to do what I want. I think
that this is a bug but it may be a feature.
For example, I have kdegraphics for x86_66 installed:
# rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | grep kdegraphics
kdegraphics-devel-3.5.4-1.fc6.x86_64
kdegraphics-devel-3.5.4-1.fc6.i386
kdegraphics-3.5.4-1.fc6.x86_64
I don't know why I had kdegraphics-devel for i386 installed. I've
now removed it.
The updates repository for x86_64 has two versions of kdegraphics:
kdegraphics-3.5.5-0.1.fc6.i386.rpm
kdegraphics-3.5.5-0.1.fc6.x86_64.rpm
I don't know why, but it ought to be harmless. It isn't.
To me, harmless would mean that this command would do nothing, but
that isn't the case:
yum localupdate kdegraphics-3.5.5-0.1.fc6.i386.rpm
Instead, here's what it proposes to do:
=============================================================================
Package Arch Version Repository Size
=============================================================================
Updating:
kdegraphics i386 7:3.5.5-0.1.fc6 kdegraphics-3.5.5-0.1.fc6.i386.rpm 18 M
Installing for dependencies:
fribidi i386 0.10.7-5.1 core 53 k
gphoto2 i386 2.2.0-2.1 core 1.4 M
libexif i386 0.6.13-2 core 149 k
libieee1284 i386 0.2.9-3.2.2 core 33 k
sane-backends-libs i386 1.0.18-5.fc6 core 2.3 M
Updating for dependencies:
arts x86_64 8:1.5.5-0.1.fc6 updates 1.2 M
kdebase x86_64 6:3.5.5-0.4.fc6 updates 29 M
kdelibs x86_64 6:3.5.5-0.2.fc6 updates 18 M
qt x86_64 1:3.3.7-0.1.fc6 updates 3.6 M
Transaction Summary
=============================================================================
Install 5 Package(s)
Update 5 Package(s)
Remove 0 Package(s)
Why would it replace an x86_64 package with an i386 package?
Given that it is doing so, why does it care at all about x86_64 libraries (like kdelibs and qt)?
Curiouser and curiouser: these two commands act differently:
yum localupdate kdegraphics-3.5.5-0.1.fc6.i386.rpm kdegraphics-3.5.5-0.1.fc6.x86_64.rpm
yum localupdate kdegraphics-3.5.5-0.1.fc6.x86_64.rpm kdegraphics-3.5.5-0.1.fc6.i386.rpm
I would have expected yum to ignore order (and pick the newest best match).
The first proposes to do this, a natural extension of above. This is
a natural extension of what the previous just-i386 command proposed to
do. I would rather that it realized that the x86_64 version trumped
the i386 version (ie. closer to being an update).
=============================================================================
Package Arch Version Repository Size
=============================================================================
Updating:
kdegraphics x86_64 7:3.5.5-0.1.fc6 kdegraphics-3.5.5-0.1.fc6.x86_64.rpm 19 M
kdegraphics i386 7:3.5.5-0.1.fc6 kdegraphics-3.5.5-0.1.fc6.i386.rpm 18 M
Installing for dependencies:
fribidi i386 0.10.7-5.1 core 53 k
gphoto2 i386 2.2.0-2.1 core 1.4 M
libexif i386 0.6.13-2 core 149 k
libieee1284 i386 0.2.9-3.2.2 core 33 k
sane-backends-libs i386 1.0.18-5.fc6 core 2.3 M
Updating for dependencies:
arts x86_64 8:1.5.5-0.1.fc6 updates 1.2 M
kdebase x86_64 6:3.5.5-0.4.fc6 updates 29 M
kdegraphics-devel x86_64 7:3.5.5-0.1.fc6 updates 106 k
kdelibs x86_64 6:3.5.5-0.2.fc6 updates 18 M
qt x86_64 1:3.3.7-0.1.fc6 updates 3.6 M
Transaction Summary
=============================================================================
Install 5 Package(s)
Update 7 Package(s)
Remove 0 Package(s)
The second balks with this error message:
Error: Missing Dependency: kdegraphics = 7:3.5.4-1.fc6 is needed by package kdegraphics-devel
What the heck? It is unfortunate that this dependency does not
mention %{ARCH}. Even so, it makes no sense since both archs'
packages will be present
This looks like a bug to me. Is there a reasonable explanation?
