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

[Florian Festi]

Tim Lauridsen wrote:
> Florian Festi wrote:
>> Tim Lauridsen wrote:
>>> Florian Festi wrote:
>>>> Shouldn't
>>>>
>>>> depTree = self._buildDepTree()
>>>>
>>>> be done in the while loop as the tsInfo changes with each loop?
>>>>
>>>
>>> No need to build the depTree again, it is just used to find the relation
>>> between packages original in the transaction and which packages they 
>>> drag in as dependcies.
>>> So if foo is needed to be skipped then foobar & foogui dragged in as 
>>> deps to foo is skipped too.
>>> If we recalc the deptree in each loop, then we lose some relations, 
>>> because some packages is removed, and we can get looping in special 
>>> cases.
>>
>> What about the deps of the packages we draw in in the while loop. An 
>> alternative also satisfying a requirement - if this can happen. I've 
>> been sent the following Traceback (devel update):
>>
>>  --> Finished Dependency Resolution
>>  Traceback (most recent call last):
>>    File "./yummain.py", line 204, in <module>
>>      main(sys.argv[1:])
>>    File "./yummain.py", line 146, in main
>>      (result, resultmsgs) = base.buildTransaction()
>>    File "/.../yum/yum/__init__.py", line 588, in buildTransaction
>>      rescode, restring = self._skipPackagesWithProblems(rescode, 
>> restring)
>>    File "/.../yum/yum/__init__.py", line 604, in 
>> _skipPackagesWithProblems
>>      toRemove = self._getPackagesToRemove(wpo, depTree, toRemove)
>>    File "/.../yum/yum/__init__.py", line 636, in _getPackagesToRemove
>>      for child in deptree[po]:
>>  KeyError: <yum.sqlitesack.YumAvailablePackageSqlite object at 
>> 0x10aca410>
>>
>> Tghis can obviosly only happen in the second run of the while loop. So 
>> I guess the deptree needs to be updated somehow.
>>
>> Florian
>> _______________________________________________
>> Yum-devel mailing list
>> Yum-devel at linux.duke.edu
>> https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
> 
> I don't see how other deps can be dragged in a second depsolve run, not 
> in the inital transaction result. after we have removed some packages
> from the transaction.
> 
> How do you get this Traceback, do you have a testcase.
> Are you using current yum master.

This was yesterdays master +  the patch you've sent on the mailing list. I 
am sorry, but the test case no longer exists.

If I understand the patch right you remove  packages that have problems 
(lets say an unresolved dependency) and all txmbrs of packages that got 
updated/obsoleted by that package (lets say there are none) and recursivly 
all packages (txmbrs) that got into the TsInfo as a dependency of that package.

So if this package is removed it is possible that is is required by another 
package if this package was pulled in a a new requirement (and not as an 
required update). This leaves a unsatisfied requirement that is capable to 
pull in another package. This situation should lead to the Traceback shown 
above if this package also cannot be installed.

Sinmple example:

Repo
foo requires:bar
bar requires:baz
bar-ng provides:bar requires:baz

install foo
Resolving
First round
foo, bar -> unresolved bar requires: baz
removing bar
Resolving
Second round
foo, bar-ng -> unresolved bar-ng requires: baz
removing bar-ng
-> Traceback bar-ng not in deptree

Did I miss something?

Florian

Btw: As "toRemove" has a fair chance of getting big it might be worth using 
a set.