Bug 1537322

Summary:	Yum update behavior is inconsistent with yum install behavior
Product:	Red Hat Enterprise Linux 7	Reporter:	nathan
Component:	yum	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	7.7	CC:	emrakova, james.antill, mdomonko
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-11-06 13:56:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description nathan 2018-01-23 00:04:47 UTC

Description of problem:
When installing a package with yum, it will correctly choose the package for your operating system, even if a package with a higher version number exists for a different operating system.

However, when updating, it will ignore your operating system and indiscriminately grab any package for any operating system or architecture, as long as the version number is higher.

This can lead to yum updates breaking on a system, simply because a repository is misconfigured.  Sloppy repository maintenance should be not be able to break yum updates so easily.


Version-Release number of selected component (if applicable):
Any verision of yum
Any version of RHEL or CentOS.


How reproducible:
Always

Steps to Reproduce:
1. On an x86_64 system, add the following repository: https://sea.fedorapeople.org/repo/
2.  Install notepadqq
3.  Attempt yum update

Actual results:
Error: Package: notepadqq-0.46.1-1.fc20.i386 (FedoraPeople-sea)
           Requires: libQt5WebKitWidgets.so.5
Error: Package: notepadqq-0.46.1-1.fc20.i386 (FedoraPeople-sea)
           Requires: libQt5WebKit.so.5
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Expected results:
Yum update succeeds and does not try to upgrade your package to the wrong architecture and OS version.

Additional info:
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]
Installed:
  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)
           Requires: libQt5WebKitWidgets.so.5
Error: Package: notepadqq-0.46.1-1.fc20.i386 (FedoraPeople-sea)
           Requires: libQt5WebKit.so.5
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


So in conclusion I 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. 

While I understand that this is caused (on the update) by a misconfigured repo, when doing the yum install, yum is clearly using the filename on the yum install command to filter by the x86_64.el7 string and properly ignoring the larger version number because it has fc20 and i386 in the package filename.

Related:
https://bugs.centos.org/view.php?id=14279
https://bugs.centos.org/view.php?id=14275

Comment 2 Michal Domonkos 2018-11-06 13:56:41 UTC

The reason "yum install notepadqq" picks notepadqq.x86_64 0:0.46.1-0.el7.centos is not the dist tag but the arch matching the underlaying system.  It is controlled by the multilib_policy setting (see yum.conf(5) for details).  In your case, you most likely have it set to "best".

On the other hand, when updating, yum always picks the latest available package, even if it's a different arch.  However, since RHEL-7.5, it's possible to say that specific packages shouldn't change their architecture in updates using the exactarchlist setting (again, see the man page).  To make all packages stick to their current arch, you can set exactarchlist=* in yum.conf.  However, the default is an empty list.

Why multilib_policy is not honored on updates as well, I'm not entirely sure, but that's how things have always been.  My guess is that this is to cover for packages changing the architecture they're built for (e.g. noarch -> x86_64).  

Either way, I'm afraid we cannot change the default behavior at this point without risking breakage for existing (enterprise) users who may rely on it for one reason or another.  There's a related BZ with some more details:
https://bugzilla.redhat.com/show_bug.cgi?id=1361609#c5

Therefore, I'm closing this as WONTFIX.