[Yum-devel] [Patch] Resolver Performance and Correctness
katzj at redhat.com
Tue Jun 12 15:28:15 UTC 2007
On Mon, 2007-06-11 at 17:49 +0200, Florian Festi wrote:
> Jeremy Katz wrote:
> > On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote:
> >> * new _checkInstall, _checkRemove,
> >> * dropped _provideToPkg and _requiredByPkg
> >> * _checkConflicts, _checkFileRequires - work globally
> >> * ignoring installed problems and problems in updates properly?
> > Have to look at these closer to really assess correctness. And where
> > one change at a time helps a lot.
> Hmm, don't know if smaller patches would help here much... Some notes on
> these methods:
Sure it can...
> The resolving itself is adjusted/simplified for the new search methods. It
> now adds the pkg to all matching packages as requires. This feels more right
> than the old code although I am not yet sure about the exact semantic of
> that .relatedto/.depends_on code...
So this can be broken down into one patch. To stand on its own. And
yeah, the relatedto/depends_on semantics are ... non-obvious. Probably
worth spending a little bit of time documenting it.
> Moved the conflict handling code out of _checkInstall because we need to
> loop over all conflicts not just the ones in the newly installed pkgs. Could
> be done in a separate patch but I didn't want to write it twice as it is
> much shorter with the new interface.
Patches can depend on each other and have to be applied in series. So
there's no reason it would have to be written twice. Just split out as
something to apply independent of any of the other things here. And
more importantly, that can be independently bisected on rather than
having the case where we get the patches applied and find a case that we
used to be okay on but break with now. And then having to go and look
through a 1500 line diff to try and find the problem.
> As the search is just one call now I merged the whole algorithm into a
> single set of nested loops. But in fact nothing really changed here except
> that files move out into a separate method.
So move the files check out into a separate method _first_ as its own
step and then have the simple patch that just merges things down.
> Ok, that's the difficult one...
> Rational between that method is that there are much more files that there
> are file requires. So it trades the number of files within the removed pkgs
> for the number of overall file requirements. This is a bad deal for very
> small transactions but pays of comparably fast.
*nod* The question is where is the tipping point. And is the cost for
the smaller ones worth it (probably). Also, the additional sets you
allude to are going to have a cost as far as memory usage that has to be
weighed as well. But making the move to having this split out and on
its own as a change on its own is going to be a lot easier to go with
than just doing it as part of the big thing.
More information about the Yum-devel