Description of problem: When upgrading packages via UI with Satellite System Set Manager (SSM), multiple versions of the same package are sent to the client as the list of packages are upgraded, this should not be the case. Satellite should take the package subset, and if more than one version is selected via UI, it should only pass the latest version of that subset and its dependencies to the client. Version-Release number of selected component (if applicable): Multiple versions of Satellite - 5.0.1, and 5.1.1 being the later ones. How reproducible: Always. Steps to Reproduce: 1. Provision or register a RHEL client to Satellite; 2. Select this system profile on Systems page, then via the SSM choose upgrade packages; 3. Multiple versions of the same packages are available in the UI, which is correct, because it allows upgrading to pkgs that are not the latest version. 4. Choose a package and proceed to schedule the upgrade / install. Do a rhn_check (-vvvvv) on client to see that it fails. Now up2date (--dry-run to test then -vvvvv to run) to see that updating the same pkgs succeeds whereas upgrading via rhn_check did not. Notice how rhn_check output/logs will contain multiple versions of the same package. 5. ***Note also the way SSM does upgrade and installs are not consistent, installs should also allow packages that are not the latest version, similar to upgrade. Actual results: Upgrade via SSM/rhn_check fails. Expected results: That it doesn't :) Additional info: See history in previous comment.
*** Bug 436852 has been marked as a duplicate of this bug. ***
Commit: dee3fe6fba92a5e36a1d35118a832a2264588f59 I had recently ported the SSM pages to Java, so the changes aren't easily applicable for retrofitting to the perl page. When reading the user selected packages from the UI, I added logic to keep the most recent version (using the existing PackageEvr compareTo method).
1. I took 5 different package versions: v0,v1,v2,v3,v4 2. I created a new rhel4 custom channel, pushed the oldest v0 package version to the channel and installed it on the client. 3. I pushed 4 newer versions to the same channel. 4. I scheduled package upgrade via SSM by selecting v1 and v2 versions. Version v2 was correctly installed. 5. Then I scheduled v3 and v4 to upgrade. Correctly the latest version was installed. Stage validated -> RELEASE_PENDING.
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/RHEA-2009-1434.html