Description of problem: A rawhide update from today brought libwnck-2.19.3.1-1.fc8. yum did not protest about broken dependencies nor tried to find some additional updates but 'package-cleanup --problems' afterwards resulted in this: Package compiz requires libwnck-1.so.21()(64bit) Package gnome-applets requires libwnck-1.so.21()(64bit) Package gnome-power-manager requires libwnck-1.so.21()(64bit) with compiz-0.3.6-10.fc8, gnome-applets-2.18.0-9.fc8 and gnome-power-manager-2.19.2-2.fc8 installed. How come? Version-Release number of selected component (if applicable): yum-3.2.0-1.fc7
After today updates complaints above were resolved; but after a straight 'yum update' those were replaced by: Package k3b requires libmpcdec.so.3()(64bit) Indeed, a corresponding package was updated to libmpcdec-1.2.6-2.fc8 and that one does not provide libmpcdec.so.3. It looks that yum really stopped paying attention to dependencies, at least sometimes, and I have a gnawing suspicion that this may be true for F7 as well.
Are you using --skip-broken or using something like the yum shell (or pirut/yumex) and deselecting things after getting a failure?
> Are you using --skip-broken ... Nope! As I said in comment #1 these were results of a straight 'yum update'. No other options although 'yum-skip-broken' package is indeed present on an installation. BTW - it would be nice if one could rely, when needed, on 'skip-broken'. This used to work in the past. Oh, and when I looked closer k3b was even in the same set of updates from today together with libmpcdec.
This sounds a whole lot what like I reported and Jeremy already fixed on yum-devel: https://lists.dulug.duke.edu/pipermail/yum-devel/2007-June/003753.html
There seems to be here some extra twist though. The referenced message from 'yum-devel' says: > when a > package which is not part of the transaction set gets it's dependencies > broken by an update. As noted in comment #3 both 'k3b' and 'libmpcdec' packages were parts of the same transanction. Still 'k3b' ended up with broken dependencies (and, as for now, rawhide 'k3b' still is in that way). One can only hope that the same fix is applicable.
Okay, this should be fixed up in yum cvs (I fixed another case where this can occur). yum 3.2.1 should be out shortly and will have the fix
You guy might be interested in the thread starting at https://www.redhat.com/archives/fedora-list/2007-June/msg03185.html seems to me as if yum-3.2.0 is deep in limbo.