Description of problem:
A rawhide update from today brought libwnck-188.8.131.52-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):
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
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
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
seems to me as if yum-3.2.0 is deep in limbo.