Description of problem: While working on customer issue IT 143771/BZ 429627 it was found that scheduling a upgrade of packages then run the job via rhn_check results in failure due to dependency failure/file conflicts. Up2dating the same packages work fine, and the problem is not package-specific. The issue was originally found on RHEL3, but given where we're for that, filing a bug for RHEL4 (where it's also reproducible) per discussion with Prad. Version-Release number of selected component (if applicable): up2date-4.6.2-7.el4_6.1 rhnlib-2.1.1-9.el4_6 How reproducible: Always. Steps to Reproduce: 1. Provision a RHEL4U1 client, say on a 5.0.1 satellite; 2. Select this system profile then via the SSM schedule a package upgrade (either all pkgs to get it to go to RHEL4U6, or specific pkgs, such as audit*); 3. 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. Actual results: Upgrade via SSM/rhn_check fails. Expected results: That it doesn't :) Additional info: Logs/outputs attached. Once an IT is cloned from original customer issue, will attach here.
Per discussion with Prad just now, we're going to split off a bug from this one (which is client side) to address the Satellite-side issue. There're 2 problems - Satellite should not schedule more than one version of the package to be installed/upgraded, and the client side should be able to handle the file/dependencies correctly. It's possible that once the former is fixed we see problems in the latter go away, but we need to fix the Satellite side to make sure it's giving client the right package list to begin with. Thus the new spinoff BZ will be for Satellite which this one will depend on. Xixi
Satellite-side bug 465892 created.