[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