Red Hat Bugzilla – Bug 164188
dependency problem terminates up2date and/or yum update
Last modified: 2007-11-30 17:11:10 EST
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 2.6.11.5-20050601.152643.FC requires /lib/modules/2.6.12-1.1390_FC4 dlm-kernel 2.6.11.5-20050601.152643.FC4 requires /lib/modules/2.6.12-1.1390_FC4 gnbd-kernel 2.6.11.2-20050420.133124.FC requires /lib/modules/2.6.12-1.1390_FC4 Version-Release number of selected component (if applicable): How reproducible: Always 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!
installed kernel is 2.6.12-1.1398_FC4 (from very first run of up2date, I think)
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 gives: cman-kernel-2.6.11.5-20050601.152643.FC4.2 cman-kernel-2.6.11.5-20050601.152643.FC4.9 dlm-kernel-2.6.11.5-20050601.152643.FC4.2 dlm-kernel-2.6.11.5-20050601.152643.FC4.10 package gndb-kernel is not installed in more words.. rpm -qa | grep -P 'cman|dlm|gndb' gives: cman-kernel-2.6.11.5-20050601.152643.FC4.9 dlm-devel-1.0.0-3 cman-1.0.0-1 dlm-kernheaders-2.6.11.5-20050601.152643.FC4.10 cman-kernheaders-2.6.11.5-20050601.152643.FC4.9 cman-kernel-2.6.11.5-20050601.152643.FC4.2 dlm-kernel-2.6.11.5-20050601.152643.FC4.10 dlm-kernel-2.6.11.5-20050601.152643.FC4.2 dlm-1.0.0-3 ==== ALSO: 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. Namely: ------ up2date continue wierdness yum update not continuing after something (one of many) fails ..thanks again, ..jim Thanks to all ..jim
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 2.6.11.8-20050601.152643.FC4 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 2.6.11.5-20050601.152643.FC requires /lib/modules/2.6.15-1.1831_FC4 dlm-kernel 2.6.11.5-20050601.152643.FC4 requires /lib/modules/2.6.15-1.1831_FC4 gnbd-kernel 2.6.11.2-20050420.133124.FC requires /lib/modules/2.6.15-1.1831_FC4 The following packages were added to your selection to satisfy dependencies: Package Required by ---------------------------------------------------------------------------- ~
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.
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 GNU/Linux yum-2.6.1-0.fc5 and, generally, everything else up-to-date as/of this post. Regards, ..jim
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.