Bug 146278 - yum fails to resolve dependencies and upgrade packages
yum fails to resolve dependencies and upgrade packages
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-26 12:42 EST by james
Modified: 2014-01-21 17:51 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-26 12:46:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description james 2005-01-26 12:42:42 EST
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:
Comment 1 Seth Vidal 2005-01-26 12:46:05 EST
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.
Comment 2 james 2005-01-30 12:16:04 EST
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.
Comment 3 Seth Vidal 2005-01-30 12:22:13 EST
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'?

Comment 4 james 2005-01-30 18:26:07 EST
> 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?
Comment 5 Seth Vidal 2005-01-30 18:39:31 EST
> 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?
Comment 6 james 2005-01-30 23:02:07 EST
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.
Comment 7 Seth Vidal 2005-01-30 23:38:08 EST
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
Comment 8 james 2005-01-31 00:44:49 EST
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?

Note You need to log in before you can comment on or make changes to this bug.