Bug 436852 - Upgrading packages via SSM/rhn_check fails due to dependency/conflict handling issues
Upgrading packages via SSM/rhn_check fails due to dependency/conflict handlin...
Status: CLOSED DUPLICATE of bug 465892
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Pradeep Kilambi
Fanny Augustin
Depends On: 465892
  Show dependency treegraph
Reported: 2008-03-10 15:30 EDT by Xixi
Modified: 2008-12-15 18:25 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-15 18:25:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Xixi 2008-03-10 15:30:57 EDT
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):

How reproducible:

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.
Comment 7 Xixi 2008-10-06 19:42:18 EDT
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.

Comment 8 Xixi 2008-10-06 19:49:26 EDT
Satellite-side bug 465892 created.

Note You need to log in before you can comment on or make changes to this bug.