Florian Festi wrote:
Sorry. It looks like the skip broken code works exactly the opposite way
I thought: It removes the packages that leads to the problem.
I've commited two test cases that give an idea why this might not be the
best strategy (hmm, may be I should add some doc strings...).
OK, I should be a bit more verbose here. I just wanted to avoid anyone
spending unnecessary time with my example.
Going up dep graph has two problems:
1. We do not remove the packages we added for dependency. We can end up with
just adding a library package that is not used by anyone as the requiring
package got removed. This sucks. So going into the other direction is a must.
2. Removing all the packages that lead to the problems doesn't give a chance
to use an alternative package that might be available and fixes the problem.
To be able to do this we would only remove the package having the problem
and try if the depsolving finds a better solution. If not we can remove the
package one level up as it has unresolved deps now. This means we may not
remove packages up the dep tree at all and we need to make sure that the
broken packages are not added again. This may require more time but will
lead to better results - especially if yum can pull in packages that are
newer than the installed but not the newest available.
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
