Description of problem:
yum is not honoring the preferred hardware architecture when updating packages. For example, repository containing:
===========================================
Package Arch Version Repository
===========================================
dummy.x86_64 1-1 testrepo
dummy.i686 1-2 testrepo
Yum will install dummy-1-2.i686 because the version is newer, even though the x86_64 version is already installed.
This is true even when /etc/yum.conf has the following directives set:
exactarch=1
multilib_policy=best
protected_multilib=1
It is understood that it is bad form to have the package versions/arch out of sync like this. However, the concern is that in the event that a problem occurred and the repository *accidentally* became out of sync, the expectation is that yum should fail to warn of the issue rather than simply change arch of many packages potentially causing a disruption of service.
# yum update dummy.x86_64
testrepo | 2.9 kB 00:00:00
Resolving Dependencies
--> Running transaction check
---> Package dummy.x86_64 0:1-1 will be updated
---> Package dummy.i686 0:1-2 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
===================================================================================
Package Arch Version Repository Size
===================================================================================
Updating:
dummy i686 1-2 testrepo 1.5 k
Transaction Summary
===================================================================================
Upgrade 1 Package
Version-Release number of selected component (if applicable):
RHEL 7.2
yum-3.4.3-132.el7.noarch
rpm-4.11.3-17.el7.x86_64
How reproducible:
Steps to Reproduce:
1. yum install -y createrepo httpd
2. systemctl start httpd
3. Copy attached rpms (dummy-1-1.x86_64.rpm dummy-1-2.i686.rpm)
to /var/www/html/testrepo
4. Copy attached testrepo.repo into /etc/yum.repo.d/
5. Add the following directives to /etc/yum.conf
exactarch=1
multilib_policy=best
protected_multilib=1
6. confirm the test repo configured
yum repolist
7. confirm both packages available from repo
yum list dummy
8. Install dummy. Note that it installs lower versioned, x86_64 package
yum install dummy
9. Update dummy. Note that it installs the higher versioned, i686 package,
even though x86_64 might be specified.
yum update dummy.x86_64
Actual results:
Yum upgrades to dummy-1-2.i686.rpm, honoring the version number over the architecture.
Expected results:
Yum, with the directives configured, would either generate an error or simply
not update the package since the $arch is different.
dummy-1-1.x86_64.rpm would remain installed.
Additional info:
Note the follow BZs are possibly somewhat related, all involving the upgrades and new i686 (32 bit) version of OpenJDK.
bz1395397 - Bug: In-place upgrade installs wrong version of OpenJDK
bz1388520 - installing java-1.8.0-openjdk.i686 installs incorrect x86_64 dependencies
bz1361609 - Yum changes arch of package if repository becomes out of sync with 32bit OpenJDK
Comment 12Valentina Mukhamedzhanova
2017-03-15 14:31:25 UTC
*** Bug 1428716 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0845
Description of problem: yum is not honoring the preferred hardware architecture when updating packages. For example, repository containing: =========================================== Package Arch Version Repository =========================================== dummy.x86_64 1-1 testrepo dummy.i686 1-2 testrepo Yum will install dummy-1-2.i686 because the version is newer, even though the x86_64 version is already installed. This is true even when /etc/yum.conf has the following directives set: exactarch=1 multilib_policy=best protected_multilib=1 It is understood that it is bad form to have the package versions/arch out of sync like this. However, the concern is that in the event that a problem occurred and the repository *accidentally* became out of sync, the expectation is that yum should fail to warn of the issue rather than simply change arch of many packages potentially causing a disruption of service. # yum update dummy.x86_64 testrepo | 2.9 kB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package dummy.x86_64 0:1-1 will be updated ---> Package dummy.i686 0:1-2 will be an update --> Finished Dependency Resolution Dependencies Resolved =================================================================================== Package Arch Version Repository Size =================================================================================== Updating: dummy i686 1-2 testrepo 1.5 k Transaction Summary =================================================================================== Upgrade 1 Package Version-Release number of selected component (if applicable): RHEL 7.2 yum-3.4.3-132.el7.noarch rpm-4.11.3-17.el7.x86_64 How reproducible: Steps to Reproduce: 1. yum install -y createrepo httpd 2. systemctl start httpd 3. Copy attached rpms (dummy-1-1.x86_64.rpm dummy-1-2.i686.rpm) to /var/www/html/testrepo 4. Copy attached testrepo.repo into /etc/yum.repo.d/ 5. Add the following directives to /etc/yum.conf exactarch=1 multilib_policy=best protected_multilib=1 6. confirm the test repo configured yum repolist 7. confirm both packages available from repo yum list dummy 8. Install dummy. Note that it installs lower versioned, x86_64 package yum install dummy 9. Update dummy. Note that it installs the higher versioned, i686 package, even though x86_64 might be specified. yum update dummy.x86_64 Actual results: Yum upgrades to dummy-1-2.i686.rpm, honoring the version number over the architecture. Expected results: Yum, with the directives configured, would either generate an error or simply not update the package since the $arch is different. dummy-1-1.x86_64.rpm would remain installed. Additional info: