seth vidal wrote:
On Fri, 2007-03-23 at 03:13 -0400, seth vidal wrote:
Hey,
I was looking at the tsInfoDelta code that James first added and then
at the patch that Florian sent and something worries me. Take the
following case from:
quux requires bar
quux is in a repository
bar is installed on the system
I run the following yum shell commands:
install quux
remove bar
ts solve
3.1.X will remove bar and install quux leaving quux with a broken dep. -
something that I'll work on fixing shortly.
3.0.X will bitch at you and complain that the dep on bar is
unresolveable.
I'm curious how we will ever be able to handle the above situation
without rechecking all pkgs in the transaction on every change to the
transaction set.
Is there something I'm missing?
okay, we might be able to scoot around this problem but I'll work on the
following changes:
1. make sure that every separate call to resolveDeps resets the
tsInfoDeltas
- so that if someone does: install foo; ts solve; remove bar; they
don't end up not rechecking foo in light of bar being removed
If the delta resolver really works resetting the delta is not needed. You
just have to make sure that really every change gets into the delta.
Removing and formaerly added package again has to be treated as a remove in
the delta.
2. we probably need to enhance _checkRemove to make sure it does:
a. account for any installed pkg requiring anything provided by the
pkg being removed
This should already be the case.
b. account for any package_to_be_installed/updated requiring anything
provided by the pkg being removed
Yes, this is missing and the delta resolving can't work without.
The Depsolver.deps cache is another source of errors as it returns outdated
information.
- I think it's just an ordering problem right now but I might end up
with a separate semi-private method like _provideToPkg() but kinda the
opposite (_requiredDep())
This whole searching looks a bit messy at first sight. May be consistent
interfaces and implementations for all Prcos and different type of package
sacks/piles would be useful. I see no reason why a transaction shouldn't be
seen as a package sack and provide the same search functions as all others.
Moving the search functions to the right places will also make further
optimization easier.
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
