Bug 1034842

Summary: Upgrade a package specified in "Activation Key -> Packages" during registration if an older release is already installed
Product: [Community] Spacewalk Reporter: Lionel Le Folgoc <lionel>
Component: ClientsAssignee: Milan Zázrivec <mzazrivec>
Status: CLOSED NOTABUG QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.1   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-24 10:01:11 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:
Bug Depends On:    
Bug Blocks: 1484117    

Description Lionel Le Folgoc 2013-11-26 15:30:27 UTC
Hi,

During the initial registration to spacewalk, if a package is specified in "Activation Key -> Packages" for the key used and already installed on the system at an older release, rhnreg_ks won't trigger an upgrade of the package to the latest release. This used to work in the past.

For example:
- package foo 1.0-1 on the player
- latest release on the spacewalk channels is foo 1.1-1
- the activation key X-BAR-MYKEY contains "foo" in "Activation Key -> Packages".
- rhnreg_ks --activationkey X-BAR-MYKEY on the player
- we expect foo to be upgraded to 1.1-1, but it's still 1.0-1.

This was working in Spacewalk/yum-rhn-plugin 1.2 (e.g., fc14 systems), but doesn't work anymore in e.g. Spacewalk/yum-rhn-plugin 1.9 (e.g., fc17 and fc18 systems).

The regression is apparently caused by commit ea84c915032450b540b1dd47c8062a6cfc4c3d11 <https://git.fedorahosted.org/cgit/spacewalk.git/commit/client/rhel/yum-rhn-plugin?id=ea84c915032450b540b1dd47c8062a6cfc4c3d11>. I couldn't find any bug referencing that commit, nor does its commit message reference any bug report.

I rebuilt yum-rhn-plugin 1.9.4 locally, reverting the above commit, and the registration behaves as expected/previously (foo is upgraded to 1.1-1).
I couldn't find any "new" bug during my (limited) testing with this patched package.

Could this behavior be reintroduced somehow?
This would be rather useful to force an upgrade of a known broken/outdated package during registration (like what happened with one version of rhnsd having an incomplete systemd service file (Missing Type=forking) on fc17, causing rhnsd to not start on some systems).

Thanks!

Comment 1 Lionel Le Folgoc 2014-02-24 10:01:11 UTC
After some more testing, I can see why this was introduced (if some/all packages are already installed, the initial deployment will fail). Closing.

Comment 2 Eric Herget 2017-09-28 18:11:48 UTC
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.