Bug 1566648 - using yum with --advisory option installs packages newer than the advisory selected
Summary: using yum with --advisory option installs packages newer than the advisory se...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: yum
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-12 17:02 UTC by James T Mills
Modified: 2018-11-26 14:17 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-22 17:25:28 UTC
Target Upstream Version:


Attachments (Terms of Use)
output of yum updateinfo, and yum --advisory (30.49 KB, text/plain)
2018-04-12 17:02 UTC, James T Mills
no flags Details

Description James T Mills 2018-04-12 17:02:32 UTC
Created attachment 1420963 [details]
output of yum updateinfo, and yum --advisory

Description of problem:
Attempting to install packages from a specified advisory and yum installs newer versions of the package than those listed in the advisory.

Version-Release number of selected component (if applicable):
RHEL 7.4 system trying to apply RHBA-2017:2581 which should provide kernel-3.10.0-693.2.1.el7.x86_64.  Using yum updateinfo also returns this information. However, when running the command, the kernel is actually upgraded to kernel.x86_64 0:3.10.0-862.el7

How reproducible:
Seems to happen every time.

Steps to Reproduce:
1. Have a RHEL 7.4 system with kernel older than 3.10.0-693.2.1.el7.x86_64.
2. run
# yum updateinfo list kernel
Loaded plugins: product-id, search-disabled-repos, subscription-manager
This system is not registered with an entitlement server. You can use subscription-manager to register.
RHSA-2017:2473 Important/Sec. kernel-3.10.0-693.1.1.el7.x86_64
RHBA-2017:2581 bugfix         kernel-3.10.0-693.2.1.el7.x86_64
RHSA-2017:2679 Important/Sec. kernel-3.10.0-693.2.2.el7.x86_64
RHSA-2017:2930 Important/Sec. kernel-3.10.0-693.5.2.el7.x86_64
RHSA-2017:3315 Moderate/Sec.  kernel-3.10.0-693.11.1.el7.x86_64
RHSA-2018:0007 Important/Sec. kernel-3.10.0-693.11.6.el7.x86_64
RHSA-2018:0151 Important/Sec. kernel-3.10.0-693.17.1.el7.x86_64
RHSA-2018:0395 Important/Sec. kernel-3.10.0-693.21.1.el7.x86_64
updateinfo list done

 
3. run
# yum update --advisory=RHBA-2017:2581

Actual results:
Instead of kernel-3.10.0-693.2.1.el7.x86_64 being installed, kernel.x86_64 0:3.10.0-862.el7 is.

Expected results:
kernel-3.10.0-693.2.1.el7.x86_64 being installed

Additional info:
It is interesting to note that kernel.x86_64 0:3.10.0-862.el7 does not show at all in yum updateinfo list kernel even though it is obviously available and installs. It appears there is no metadata for this that yum updateinfo can parse?

Comment 2 Karel Srot 2018-11-12 08:34:29 UTC
Yum install latest available packages. AFAIK --advisory option only adds respective package updates to the transactions, not necessarily specific NVRs. 
Can you try update-minimal command eventually?

Comment 3 Michal Domonkos 2018-11-22 17:25:28 UTC
I confirm; yum always picks up the newest available version.

In general, when installing/updating packages, yum assumes that you always want the latest greatest, unless you select a specific NEVRA.

With advisories specifically, though, the latter is not supported (nor desired).  Yum will always pick the latest advisory for each package.  The rationale is that, when an advisory is released and distributed in the updateinfo.xml files, any previous versions of the same advisory become irrelevant (even though they're still listed in the xml and displayed when using "updateinfo list", for example) and users shouldn't really update to those as they could, for example, contain security flaws that have been addressed in a newer advisory.

So, in practice, --advisory is only useful for selecting which packages you want to update, as Karel mentioned.

That said, if you really need to apply an older advisory for some reason, update-minimal is your friend.  I have tried it and it worked as you'd expect.

Comment 4 James T Mills 2018-11-26 14:17:20 UTC
update-minimal seemed to work for my limited testing.  Thank you for your assistance.


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