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
*** Bug 523307 has been marked as a duplicate of this bug. ***
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.
Taking for now.
Fix to properly retrieve the epoch (to be able to add it to path) committed to Spacewalk master: f67b418c62184fc755670e98b0b7657e828d41a0.
Fix to move files with paths without epoch, created by previous run of update-packages, to final location: Spacewalk master: 3918b00a462e27fd8e7e2d5662b898f1ff078947.
Change in select, to find also paths that do not have the epoch (even if they should have it): Spacewalk master: 4f2a9c312d6183072d7e84261dd09eb80e49dc1c.
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.
satellite.git, SATELLITE-5.3: 18585b473f0e69af1704d2557c1aa946ff4a30a1
rhn-upgrade-5.3.0.24-1.el4sat & rhn-upgrade-5.3.0.23-1.el5sat
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