seth vidal wrote:
On Tue, 2007-12-11 at 15:12 +0100, Florian Festi wrote:
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.
I really hate this way of things working. It is one of the steps that
smart takes and on many occasions it is exactly opposite of what I want
to have happen. I realize this is optional behavior but it still makes
me cringe all over.
I agree, we should not try to make it to "smart", the purpose of
skip-broken is to get the broken stuff out of the transaction, and leave
the rest to be processed.
The way it should work (IMHO)
po1
dep1
dep11
dep2
dep3
dep31
dep32
po2
..
..
poN
if po1 or some of the deps has a problem, then po1 and
dep1,dep11,dep2,dep3,dep31,dep32 is remove from the transaction.
and leave the rest alone, if they have no problems.
Tim
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
