Red Hat Bugzilla – Bug 436852
Upgrading packages via SSM/rhn_check fails due to dependency/conflict handling issues
Last modified: 2008-12-15 18:25:41 EST
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):
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.
Upgrade via SSM/rhn_check fails.
That it doesn't :)
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.
Satellite-side bug 465892 created.