rpm update on multilib system ignores duplicate package name with different arch on command line

Jason Henderson jasonhen at rogers.com
Wed Nov 6 20:22:10 UTC 2013


Thank you for the reply. That does appear to be the issue. With all x86_64 packages installed and only the glibc.i686 with a differing architecture the rpm command will correctly upgrade the multilib packages.

To answer your question about yum check, it passed with no output on the original setup. Everything functioned correctly on the system except for the rpm upgrade.

[root at 64-bit rpm]# yum check
Loaded plugins: fastestmirror, tsflags
check all


Jason



----- Original Message -----
From: James Antill <james at fedoraproject.org>
To: Jason Henderson <jasonhen at rogers.com>; General discussion about the RPM package manager <rpm-list at lists.rpm.org>
Cc: 
Sent: Wednesday, November 6, 2013 12:31:09 PM
Subject: Re: rpm update on multilib system ignores duplicate package name with different arch on command line

On Mon, 2013-11-04 at 10:19 -0800, Jason Henderson wrote:

> I have a Linux distro (based on CentOS) which contains both i686 and
> x86_64 versions of some rpm packages. In the example below I want to
> upgrade the installed glibc.i686, glibc.x86_64 and glibc-common.i686
> packages at the same time.
> 
> 
> As shown the rpm command ignores the glibc.x86_64 package when
> glibc.i686 proceeds it in the list of packages to upgrade. The end
> result being that the glibc.x86_64 package is removed from the system.
[...]
> 
> Example:
> 
> [root at 64-bit]# rpm -qa | grep glibc
> glibc-2.12-1.107.el6_4.4.x86_64
> glibc-2.12-1.107.el6_4.4.i686
> glibc-common-2.12-1.107.el6_4.4.i686

This is not correct for an x86_64 arched machine. Eg. From:

http://mirror.stanford.edu/yum/pub/centos/6.4/os/x86_64/Packages/

glibc-2.12-1.107.el6.i686.rpm        23-Feb-2013 09:50     4.3M
glibc-2.12-1.107.el6.x86_64.rpm        23-Feb-2013 09:40     3.8M
glibc-common-2.12-1.107.el6.x86_64.rpm    23-Feb-2013 09:41     14M

...I'd be curious about what "yum check" says, and how the system got
into the state it is in. Likely someone did something using --nodeps
previously and, as always with --nodeps, made the problem worse.

If you want/need this weird combo. of primary i686 and secondary
x86_64, then you are mostly on your own ... neither yum nor rpm are
tested that way by the developers (or any distro.).

Fixing it (so it's x86_64 primary and i686 secondary, as normal) might
not be trivial, I guess I'd "distro-sync full" a lot.


More information about the Rpm-list mailing list