On Mon, 2007-02-12 at 17:54 -0500, Jeremy Katz wrote: > Okay, I've turned back on the use of what was the anaconda depsolver by > default. I've tested the following: > * Install of new leaf node package > * Install of new package dep tree > * Removal of leaf package > * Removal of specific version of a package > * Removal of glibc/bash > > Correctness of all seems fine[1]. As far as speed, the install cases > seem to be somewhat faster + we won't have to download headers > separately anymore. The erasure cases are at worst the same > time-wise... some cases seem to actually be faster. > > Further testing appreciated. If anyone finds a case that's not handled > properly, say something. And if anyone wants to make pretty graphs > showing things being faster, that'd be cool too >
So a couple of confusing bits: 1. it seems like we're losing a fair bit of the 'update out of fuckups' situations 2. I need to test it against some of the hairball obsoletes-as-the-result-of-an-update case. But just from going over the code I don't see how it could be handling those situations. Did I just miss something? Okay - looking at it for updates case: I did an update of libgcj with the old depsolver it caught that libgcj-devel and gcc-java would need to get updated as well to go with the new libgcj. the new depsolver didn't. I think I know what's going on. on an 'update' which is both an install and remove case it seems like we're only noticing the install case b/c that's all txmbr has in it. We need to also store and note the remove case so that the depsolver can traverse that path, too. Or, alternatively, maybe we should make a third 'update or obsoletes' case which can be traversed and allow the 'update out of pain' path that shouldn't happen on erasures, for example. I'll take a few whacks at the code but if you know what I'm saying or another path, feel free to take a look. -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
