Bug 523393

Summary: /usr/bin/update-packages creates wrong path for packages using epoch
Product: Red Hat Satellite 5 Reporter: Miroslav Suchý <msuchy>
Component: UpgradesAssignee: Jan Pazdziora (Red Hat) <jpazdziora>
Status: CLOSED ERRATA QA Contact: Brandon Perkins <bperkins>
Severity: medium Docs Contact:
Priority: high    
Version: 530CC: cperry, dherrman, jhutar, jpazdziora, mzazrivec, tao, tscherf, xdmoon
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-06 14:36:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 518256, 523386    

Description Miroslav Suchý 2009-09-15 10:24:22 UTC 
Description of problem:
After you run 
 /usr/bin/update-packages
in step 3 during satellite upgrade, the packages end with path like:
 /var/satellite/redhat/NULL/ff6/dhclient/3.0.5-18.el5/i386/ff6f3be28a106ca6bfe41770d1e4239d/dhclient-3.0.5-18.el5.i386.rpm
But after you sat-sync new packages you will get with path like:
 /var/satellite/redhat/NULL/ff6/dhclient/12:3.0.5-18.el5/i386/ff6f3be28a106ca6bfe41770d1e4239d/dhclient-3.0.5-18.el5.i386.rpm
(Epoch is added).
While some customers reports, that they could not download packages if they have the first form of path, I did not notice and impact on functionality.
I.e. even if I had path of first form I have been able to download the package.

So this may be just formal inconsistency with low priority. I suppose that users which report problem in functionality rather hit bug 523384.

Version-Release number of selected component (if applicable):
# rpm -qf /usr/bin/update-packages
spacewalk-backend-tools-0.5.28-34.el5sat
Comment 1 Xixi 2009-09-16 08:45:11 UTC 
*** Bug 523307 has been marked as a duplicate of this bug. ***
Comment 3 Jan Pazdziora (Red Hat) 2009-09-16 10:04:33 UTC 
Actually, the problem is not with that omit_epoch. The problem is that the nvrea parameter which gets passed to get_new_pkg_path comes from parseRPMFilename, which parses old_path_nvrea[-1]. And there is no epoch component in the "net-snmp-5.3.2.2-7.el5.i386.rpm" string.
Comment 4 Jan Pazdziora (Red Hat) 2009-09-16 14:11:15 UTC 
Taking for now.
Comment 5 Jan Pazdziora (Red Hat) 2009-09-16 14:20:34 UTC 
Fix to properly retrieve the epoch (to be able to add it to path) committed to Spacewalk master: f67b418c62184fc755670e98b0b7657e828d41a0.
Comment 6 Jan Pazdziora (Red Hat) 2009-09-17 12:32:09 UTC 
Fix to move files with paths without epoch, created by previous run of update-packages, to final location: Spacewalk master: 3918b00a462e27fd8e7e2d5662b898f1ff078947.
Comment 7 Jan Pazdziora (Red Hat) 2009-09-17 12:54:59 UTC 
Change in select, to find also paths that do not have the epoch (even if they should have it): Spacewalk master: 4f2a9c312d6183072d7e84261dd09eb80e49dc1c.
Comment 8 Jan Pazdziora (Red Hat) 2009-09-18 13:58:01 UTC 
Additional fix for situations when the old path is shorter than then new one (which is in all cases when going from pre-5.3 to 5.3): Spacewalk master: 013de18fe8c3b4de818140e06645096dabc4f071.
Comment 9 Milan Zázrivec 2009-09-22 12:37:06 UTC 
satellite.git, SATELLITE-5.3: 18585b473f0e69af1704d2557c1aa946ff4a30a1
Comment 12 Milan Zázrivec 2009-09-25 07:41:22 UTC 
rhn-upgrade-5.3.0.24-1.el4sat & rhn-upgrade-5.3.0.23-1.el5sat
Comment 15 errata-xmlrpc 2009-10-06 14:36:06 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1479.html