Red Hat Bugzilla – Bug 467608
Errors dependency to updates
Last modified: 2014-01-21 18:06:45 EST
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:18.104.22.168) Gecko/2008100707 Fedora/3.0.2-1.fc10 Firefox/3.0.2 FirePHP/0.1.2
Unable to update a hundred packages due to dependency issues.
Steps to Reproduce:
In recent weeks, I have some difficulties to update Fedora Rawhide in 64 bits.
In fact, some packages (one hundred) have an dependency issues that last, last (NetworkManager has over the past few weeks!), I suppose that it does not mirror unsynchronized.
Only some packages can be updated without any problems, we must select them one by one and pray that it works.
I do not know where is the problem but it is embarrassing if this bug continues to exit ...
I use deposits following: livna-devel, RPMFusion free and non-free, Rawhide.
Here is an error message for 22 packets a few weeks ago, message, which lasts (with now other packages concerned) : http://pastebin.com/f32c81192
I tried to update one by one, turning some packages and more. Nothing.
It looks like a lot of the dependency resolution failures are b/c of rpmfusion packages.
Could you run:
yum --disablerepo=rpmfusion\* --disablerepo=livna\* update
and see if it gets further?
it also look like it is vlc er is the cause of the problem, you might want to remove it to get rid of the problem.
If you have converted to use rpmfusion, you should remove the livna repositories.
yum remove livna-release
I removed livna-devel but, it not changes the situation. It's strange to yum says "removing name_package" for a update. I will install the Snap 3 to Fedora 10 and we can see...
I gave details when this install was done.
We have found the problem. Yum-remove-with-leaves is the problem. Uninstall this and the updates aren't problems. :)
What ver of yum-utils is it from? There was a bug in remove-with-leaves that caused it to be a bit too enthusiastic about removing pkgs but that was fixed a while ago, now.
I experienced this today with yum-remove-with-leaves-1.1.17-1.fc9.noarch
I did a yum update. The update was for:
faac i386 1.25-7.fc9 rpmfusion-free-updates 83 k
mencoder i386 1.0-0.98.20080903svn.fc9 rpmfusion-free-updates 3.0 M
mplayer i386 1.0-0.98.20080903svn.fc9 rpmfusion-free-updates 4.4 M
Since mencoder and mplayer require libenca.so.0 and were being removed, yum-remove-with-leaves thought it was OK to remove enca since they were being removed. But they were being updated so they were being put right back on. Since enca was marked for removal, the install of the new mencoder and mplayer failed for a dependency on libenca.so.0.
So in my humble opinion Seth, it is still not fixed.
Seems a look ahead is needed to get the depends for the new updates before deciding that a depend for the packages being replaced is no longer needed.
(In reply to comment #6)
> I experienced this today with yum-remove-with-leaves-1.1.17-1.fc9.noarch
> I did a yum update. The update was for:
> faac i386 1.25-7.fc9 rpmfusion-free-updates 83 k
> mencoder i386 1.0-0.98.20080903svn.fc9 rpmfusion-free-updates 3.0 M
> mplayer i386 1.0-0.98.20080903svn.fc9 rpmfusion-free-updates 4.4 M
> Since mencoder and mplayer require libenca.so.0 and were being removed,
> yum-remove-with-leaves thought it was OK to remove enca since they were being
> removed. But they were being updated so they were being put right back on.
> Since enca was marked for removal, the install of the new mencoder and mplayer
> failed for a dependency on libenca.so.0.
> So in my humble opinion Seth, it is still not fixed.
1.1.17 didn't have the fix. So, I believe it is fixed, just not in the version you're using.
yum-remove-with-leaves-1.1.17-1.fc8 and yum-remove-with-leaves-1.1.17-1.fc9 are the latest in the Fedora repositories.
I know this bug is against rawhide, but this is still a problem for many (most ?) Fedora users until the version that is fixed hits the Fedora repositories. Is there a prospect that this will happen soon?
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
closing as this has been fixed in yum-utils 1.1.19