[Yum-devel] [PATCH][RFC] Skip-broken support again

Tim Lauridsen tim.lauridsen at googlemail.com
Tue Dec 11 18:36:33 UTC 2007


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



More information about the Yum-devel mailing list