From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.54 [en] 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 be incompatible? 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): yum-2.1.12-1 How reproducible: Always Steps to Reproduce: 1.sudo yum update 2. 3. Actual Results: ... --> Running transaction check --> Processing Dependency: perl(Convert::BinHex) for package: perl- MIME-tools --> Processing Dependency: scribus= 0:1.2-0.fdr.1.2 for package: scribus-devel --> 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 Additional info:
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 mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core- rawhide 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.
Not true. 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 work yet. > should it remove the packages ... that are causing the dep problems? 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 >component? 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: repo base: foo provides foo-1.1 repo extras: bar requires foo-1.2 someone runs: 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 unresolveable dependencies 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?