View Issue Details

IDProjectCategoryView StatusLast Update
0014279CentOS-7yumpublic2020-06-19 03:07 Assigned To 
Status newResolutionopen 
Platformx86_64OSCentOS 7.4OS Version7.4
Product Version7.4.1708 
Summary0014279: yum incorrectly considers i386 packages to be updates to x86_64 packages
DescriptionI originally opened this bug as

However, tigalch closed the bug without actually reading the description thoroughly. I am re-opening it since he ignored the actual issue (which still exists) and apparently there is no way for me to re-open an issue that someone else closed on me.

I'll explain why his assertion was incorrect before continuing.

Tigalch asserts that "You are trying to update a CentOS-Package with one from fc20. That's not how it works, and you should stick to the version provided by CentOS. Otherwise you are on your own - thus closing this ticket. "

This is false for the following reason:
The directions for installing notepadqq ( clearly state that on RHEL (which would also apply to CentOS given the lack of CentOS specific instructions) the package is available in the following repository:

So to install, you enable that above repo and then yum install notepadqq, which (as of a few days ago) would install the proper x86_64.centos package when run on a CentOS system.

The original package (the .centos version) and the newly released update that broke things (the fc20 version) can both be seen with the following command and you can see that they both come from the same REPO (the one that is listed as the correct one for RHEL/CentOS):
yum list available notepadqq --showduplicates
Available Packages
notepadqq.x86_64 0.46.1-0.el7.centos @FedoraPeople-sea
notepadqq.i386 0.46.1-1.fc20 @FedoraPeople-sea

If you have the x86_64 version installed on a CentOS system and attempt to run yum -y update, it will try to overwrite the CentOS version with the fc20 version. This is not me trying to install an fc20 version as he asserted, this is yum seeing both the centos version that was original installed copy and the fc20 version, and yum deciding to try to 'upgrade' to the fc20 version of the incorrect platform type.

That is why this is a bug in yum itself, and not any fault of the user who is literally just following the installation directions exactly and then following a standard yum update workflow (every morning when I see that there are OS security updates, I run yum -y update which should update every package on my system for which updates are available).
Steps To ReproduceSteps to Reproduce:
sudo yum update notepadqq.x86_64
sudo yum -y update

Expected Results:
yum update succeeds

Actual Results:
---> Package notepadqq.x86_64 0:0.46.1-0.el7.centos will be updated
---> Package notepadqq.i386 0:0.46.1-1.fc20 will be an update
[cut for brevity]
--> Finished Dependency Resolution
Error: Package: notepadqq-0.46.1-1.fc20.i386 (FedoraPeople-sea)
Error: Package: notepadqq-0.46.1-1.fc20.i386 (FedoraPeople-sea)
Additional InformationWhy is a package that is installed as the x86_64 version trying to 'update' to an i386 version?

I could understand this on an initial install, but I already had an x86_64 package installed and so a package for a different platform is definitely not a valid upgrade.

I was able to get around this by adding exclude=*.i386 to my yum.conf but this should not be necessary at all.

Things like this should work out of the box without requiring the user to tweak their systems because a sloppy release by a single developer breaks their entire system yum workflow.
TagsNo tags attached.


duplicate of 0014275 closedtigalch yum incorrectly considers i386 packages to be updates to x86_64 packages 




2017-12-15 18:51

manager   ~0030755

I'm afraid you are totally mistaken.

In short, you need to file a report with the repository that provides notepadqq. yum in not to blame.

That repo ( ) has both notepadqq-0.46.1-0.el7.centos.x86_64.rpm AND notepadqq-0.46.1-1.fc20.i386.rpm in the same directory. It is not distinguishing the two arches. As a result, yum update will find a newer one as the latest. The repo should have separate metadata, one for x86_64 and another for i386. This is not the case with that particular repo, thus the issue you are seeing.

So, please contact the maintainer of that repository.


2017-12-15 18:53

administrator   ~0030757

Refer to fo rthe CentOS policy on the matter.

2017-12-15 19:07

reporter   ~0030758

Thank you for the response. Your answer seems technically correct but it does leave me with one question:

Yum does not distinguish architectures based on the actual file name of the rpm at all?

2017-12-15 19:12

reporter   ~0030759

As a follow-up this is a poor user experience that a maintainer of a repo can create a repo that breaks the ability to automatically update all packages on your system with a 'yum -y update'.

What would be the best way to request a change to this behavior and make yum smarter at recognizing the intended platform of an rpm?

Should I file an enhancement request that yum should grep rpm filenames for strings that indicate what platform they are intended for?

2017-12-15 19:42

reporter   ~0030760

here is some more testing to prove that yum behavior is inconsistent between the 'yum install' and 'yum update' commands:

yum list available notepadqq --showduplicates
Available Packages
notepadqq.x86_64 0.46.1-0.el7.centos FedoraPeople-sea
notepadqq.i386 0.46.1-1.fc20 FedoraPeople-sea

As you can see, both version of the package are available in the repo, but running yum install does *not* install the largest version number or the latest package, it installs the correct one for your platform:

yum install notepadqq
[cut for brevity]
  notepadqq.x86_64 0:0.46.1-0.el7.centos

Now, I run yum update on the same system immediately after:
yum update
[cut for brevity]
Error: Package: notepadqq-0.46.1-1.fc20.i386 (FedoraPeople-sea)
Error: Package: notepadqq-0.46.1-1.fc20.i386 (FedoraPeople-sea)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

So in conclusion I still believe this is a bug in yum. Yum install will see both versions and install the correct one for the platform, but yum update will then try to install the 'latest' while disregarding platform.


2017-12-16 17:16

manager   ~0030763

If you believe this is a bug in yum that needs to be fixed, you'd want to file a bug report upstream at CentOS is a "bug-for-bug" rebuild of RHEL, so cannot make changes like the one you suggested unless it comes from RH.

2018-01-23 00:06

reporter   ~0030992

Ok, filed


2020-06-19 03:07

reporter   ~0037165

The bug is with yum.conf. It has a declaration "exactarch=1", but that is not mentioned in man 5 yum.conf; instead the described variable is exactarchlist. So edit /etc/yum.conf:

    # DJA notes that the "exactarch" flag is not mentioned in man 5 yum.conf
    # Suspect that old yum.conf has persisted.
    # DJA added the following line:

Issue History

Date Modified Username Field Change
2017-12-15 17:45 New Issue
2017-12-15 17:57 tru Relationship added duplicate of 0014275
2017-12-15 18:51 toracat Note Added: 0030755
2017-12-15 18:53 tru Note Added: 0030757
2017-12-15 19:07 Note Added: 0030758
2017-12-15 19:12 Note Added: 0030759
2017-12-15 19:42 Note Added: 0030760
2017-12-16 17:16 toracat Note Added: 0030763
2018-01-23 00:06 Note Added: 0030992
2020-06-19 03:07 asnd Note Added: 0037165