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
[email protected]
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.
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
