Red Hat Bugzilla – Bug 146278
yum fails to resolve dependencies and upgrade packages
Last modified: 2014-01-21 17:51:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera
Description of problem:
I still have trouble getting yum to complete more than half the time.
Perhaps there is something about repositories in the configuration
files? Some more guidelines could be helpful. Can some repositories
I'm not sure how to interpret "yum... Error: missing dep: blah".
Perhaps the error message could be more informative. Regardless,
running yum results in no updates.
I had recently upgraded my system by running up2date, and actually
ran yum to see if, maybe, yum was working now. No joy.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.sudo yum update
--> Running transaction check
--> Processing Dependency: perl(Convert::BinHex) for package: perl-
--> Processing Dependency: scribus= 0:1.2-0.fdr.1.2 for package:
--> Finished Dependency Resolution
Error: missing dep: perl(Convert::BinHex) for pkg perl-MIME-tools
Error: missing dep: scribus for pkg scribus-devel
Expected Results: Complete
1. Go grab yum from rawhide - it should be yum 2.1.13 - try that out
on some of them.
2. the perl(Convert::BinHex) is a legit dep failure - the package
wasn't rebuilt in extras - that's just been corrected.
3. the scribus dep may also be a legit build failure.
if you want to work around these run:
yum --exclude=scribus\* --exclude=perl-MIME-tools update
and then it should update everything else.
But neither of the reported problems are yum bugs.
Anything that fails to result in an actual update is a bug in yum.
(Calling a bug a "feature" does not make it "notabug" - that's why
"that's not a bug, that's a feature" is a standing joke.)
> Go grab yum from rawhide
Adding the rawhide development repository
to the yum repository configuration in /etc/yum.conf and running
"sudo yum -y update yum" results in about 4 hours of ultimately
pointless computation and several screens full of failed
dependencies, mostly seeming to relate to python and libdb.
A lot of things can cause an update to fail. Most of them are
packaging problems, to be honest. If there is simply no way to achieve
dependency closure on a set of packages then do you call that a bug in
yum? should it remove the packages you have installed that are causing
the dep problems? Is that your idea of a 'solution'?
> Most of them are packaging problems, to be honest.
That is very much the issue, though, and goes to the heart of the
"resolver" program design goals, yum in this case. The _user_ does
not control the set of repositories - plural - so that any intra- or
inter-repository inconsistancy can cause a failure. That's a lot of
opportunity for failure - no fun for the user.
Let's look at this from a different angle. For the sake of argument,
if the entire universe of possible packages were installed on a
system, how could any single program fail to find a required
component? It could not fail! There always exists a universal
solution: install everything.
Any kind of dependency problem lies elsewhere, and arises because of
some additional constraint, limiting the "install everything"
solution. I don't know what yum's additional constraints are!
Really. I have to guess.
> ... dependency closure on a set of packages ...
Since I do not know what constraints yum is trying to solve for, I
literally do not know what that phrase means.
Program libraries create the most basic dependencies. Different
versions of program libraries can co-exist on a system without
problems because the linker knows about versions. A user only has
problems when the required library is not installed, and the "install
everything" solution still works in this case.
Some user programs are dependent upon other user programs in the same
way that programs are dependent upon libraries, but utterly fail to
manage version dependencies themselves. The most common group of
these would be "scripts" which rely upon interpreters - bash, python,
etc. Interpreters should be a kind of library, provided to a
"script" by the operating system, so that the OS can resolve version
dependencies automatically. Unfortunately, that's not the way things
> should it remove the packages ... that are causing the dep
How could _removing_ a package possibly solve a dependency problem?!
I'm not being rhetorical. I suspect that yum has overly constrained
the solution space. What problem is yum trying to solve that could
be solved by removing a package?
> That is very much the issue, though, and goes to the heart of the
> "resolver" program design goals, yum in this case. The _user_ does
>not control the set of repositories - plural - so that any intra- or
>inter-repository inconsistancy can cause a failure. That's a lot of
> opportunity for failure - no fun for the user.
The user does have control over the repositories. They can choose to
enable/disable them and/or exclude packages from them.
>Let's look at this from a different angle. For the sake of >argument,
>if the entire universe of possible packages were installed on a
>system, how could any single program fail to find a required
just b/c everything is installed doesn't mean all deps can be solved.
The deps could just be wrong.
> It could not fail! There always exists a universal
> solution: install everything.
Umm, no. Yum searches the repository to see if anything can resolve
the dependency. If nothing can resolve it then installing everything
will NOT correct the problem.
Let me give a very brief example:
foo provides foo-1.1
bar requires foo-1.2
yum install bar
nothing can satisfy foo-1.2 - it doesn't exist in any repository.
How would 'installing everything' fix the problem?
I do appreciate you helping me understand this.
> foo-1.2 - it doesn't exist in any repository.
I am going to assume, then, that this is a typical circumstance,
representative of the cases I've seen where an attempted update
results in several, or screens full, of dependency errors.
I can see that that would be a problem. Are there no guidelines
about what can be placed into the fedora repositories? Someone would
add a package requiring some other package where they could see that
that other package did not exist? Knowing that this will "hose" yum?
It sounds like a malicious act.
Still, this example does not address my question. Where does
removing a package solve a dependency failure? In the example,
removing foo, which would remove foo-1.1, isn't going to solve any
problem. Removing foo is not going to make bar install and run.
1. It's not a malicious act, it's a mistake.
2. if you mix repositories enough you WILL end up with conflicts and
3. some people (not me) think that removing the packages causing the
unresolve dep is the 'correct' way to handle such a problem. That's
what is meant by my comment about removing packages to resolve dep.s
You mean remove the package from the _repository_. I completely
missed that. I thought you were talking about removing installed
packages on the user's machine.
You've given an example of an unresolvalbe dependency. I'm curiousm
what would be an example of the "conflicts" you mention?
Has the user done something "wrong" when they "mix repositories
enough"? Or is "mixing repositories" the "real world" of the package
installer? I'm tying to understand where to look for the solution.
Should I form a list of rules about repositories that "don't mix"?
Or do I look for help from the package installer, from yum?