Bug 164188 - dependency problem terminates up2date and/or yum update
dependency problem terminates up2date and/or yum update
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Bret McMillan
Fanny Augustin
Depends On:
  Show dependency treegraph
Reported: 2005-07-25 16:24 EDT by James G. Sack
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-25 13:08:13 EDT
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 James G. Sack 2005-07-25 16:24:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
Unresolvable chain of dependencies:
cman-kernel requires /lib/modules/2.6.12-1.1390_FC4
dlm-kernel requires /lib/modules/2.6.12-1.1390_FC4
gnbd-kernel requires /lib/modules/2.6.12-1.1390_FC4

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.install FC4-x86_64 ("everything")
2.run up2date or yum update
3.terminates with error messages shown in description, above

Actual Results:  up2date reports error and says, go back and change selection. No update gets done unless explicit selections (other than cman-lernel, etc) are requested. It is very annoyingly impossible to select everything and then deselect the bad items.

yum update terminates with the error messages. No update gets performed.

Expected Results:  up2date should allow selective disabling after selecting all. 

yum update (in my experience) used to continue by skipping problem packages -- that would be the desired behavior. Is there a switch for this, maybe?

Additional info:

Workaround is painful, requires repeated exections of partial selection list.

yum update nicely accepts wildcard specs, though -- thanks for that!
Comment 1 James G. Sack 2005-07-25 16:26:53 EDT
installed kernel is 2.6.12-1.1398_FC4 (from very first run of up2date, I think)
Comment 2 James G. Sack 2005-07-27 00:22:46 EDT
as/of 2005-07-26, the bug seems to have gone away 
- perhaps due to correction of repository/dependencies
- perhaps due to withdrawal of gndb?

rpm -q {cman,dlm,gndb}-kernel
package gndb-kernel is not installed

in more words..

rpm -qa | grep -P 'cman|dlm|gndb'


I discovered that the up2date disabling of the continue button when unchecking 
something after selecting "all", can be fixed by unchecking and rechecking any 
selection. So that up2date behavior becomes merely an annoying wierdness.

Since the bug is no longer reproducible, the assigned developer may as well mark 
it fixed/resolved, although the up2date and yum update behaviors might still 
deserve attention. 

up2date continue wierdness
yum update not continuing after something (one of many) fails

..thanks again,

Thanks to all

Comment 3 Landon Kelsey 2006-03-04 12:05:26 EST
I've gotten several updated kernels since original FC4 install.

Now I get the below:

There was a package dependency problem. The message was:

    To solve all dependencies for the RPMs you have selected, The following
    packages you have marked to exclude would have to be added to the set:

    Package Name                        Reason For Skipping
    alsa-lib-1.0.10-3.FC4               Config modified

Unresolvable chain of dependencies:
GFS-kernel requires /lib/modules/2.6.15-1.1831_FC4
alsa-lib-devel-1.0.10-3.FC4              requires alsa-lib = 1.0.10
cman-kernel requires /lib/modules/2.6.15-1.1831_FC4
dlm-kernel requires /lib/modules/2.6.15-1.1831_FC4
gnbd-kernel requires /lib/modules/2.6.15-1.1831_FC4

The following packages were added to your selection to satisfy dependencies:
Package                                Required by

Comment 4 John Thacker 2006-10-29 15:19:18 EST
up2date was replaced by pirut and put (package pirut) as of FC5.  Only FC5 and
FC6 are currently fully supported; FC3 and FC4 are supported for security fixes
only.  If this bug occurs in FC3 or FC4 and is a security bug, please change the
product to Fedora Extras and the version to match.  If you can verify that the
bug exists in RHEL as well, please change the product and version appropriately.

The codebase for pirut and pup is quite different, but if a similar bug exists
in pirut and pup in FC5 or FC6, please change the product to pirut and the
version appropriately and update the bug report.

We apologize that the bug was not fixed before now.  The status will be changed
to NEEDINFO, and if the bug is not updated with evidence that it is a security
bug or a bug that affects RHEL, it will be closed.
Comment 5 James G. Sack 2006-10-29 16:07:59 EST
2006.10.29 jgs

The problem still exists.
I changed the version (from FC4) to FC5 and component (from up2date) to yum.

The problem that processing aborts on error rather than continuing still exists -- 
both in yum and yumex.

Here' an example
There's something wrong with the dependencies of castor but not with feh. If I 
queue both these packages in yumex and tell it to process those 2 queued items, I 
get an "Error in Dependency Resolution" dialog containing:
  Missing Dependency: stax-bea is needed by package dom4j

upon dismissing the dialog, nothing has been processed (eg not the feh package)

Similarly the command
  yum install feh castor
fails immediateluy after the message
  Error: Missing Dependency: stax-bea is needed by package dom4j
without installing feh.

With my trivial example, it is an easy workaround to remove castor from the yumex 
queue or the yum commandline, but the real annoyance is when doing an update that 
attempts to process a list of many packages to be updated.

Removing the cause of the failure is a painful chore because several of the 
targets may trigger the same dependency problem. The only workaround is to update 
a small number of packages at a time via yumex, which can be tedious.

What I expect is that yum and yumex should automatically disable the targets 
having the problematic dependency, and install everything else (or perhaps ask me 
if I want to do that).

It's possible the problem only occurs on x86_64?
BTW, I have
  2.6.18-1.2200.fc5 #1 SMP Sat Oct 14 16:59:56 EDT 2006 x86_64 x86_64 x86_64 
and, generally, everything else up-to-date as/of this post.

Comment 6 Jeremy Katz 2007-04-25 13:08:13 EDT
This is exactly how things are designed to work.  Just continuing with some part
of things could lead to a more broken system than anything else.  There's some
work on a plugin (skip-broken) that will give sort of the behavior you're going
for, but it's not currently targeted as the default.

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