Bug 1537322 - Yum update behavior is inconsistent with yum install behavior
Summary: Yum update behavior is inconsistent with yum install behavior
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: yum
Version: 7.7
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-23 00:04 UTC by nathan
Modified: 2018-11-06 13:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-06 13:56:41 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
CentOS 14279 0 None None None 2018-01-23 00:04:46 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.