[Yum-devel] Updated repository/Next refactoring steps/Request for review

Florian Festi ffesti at redhat.com
Wed Aug 1 08:20:41 UTC 2007


seth vidal wrote:
> Okay, Then this is what I misunderstood. I read through the depsolve
> branch patches, got pissed off and stopped reading the ffesti branch.
> Mea Culpa. I've gone through all the ffesti branches and have a few
> comments, otherwise I'm not grumpy anymore:

Mail simply isn't a lossless transport protocol...

> 1. I'm not sure how the tsinfo lookups you've implemented (old and new
> provides) will play with localinstall pkgs where the rpmdb and the
> packageSack

There is tsinfo.localSack - a PackageSack where local pkgs are put in while 
they are part of the transaction. Can you please check if the criteria for 
detecting local pkgs in TransactionData.add()/.remove() is correct.

> 2. about the search mechanism you implemented in sqlitesack _search. I
> think we'll need to be careful to unset the matched items in much the
> same way we need to be careful about figuring out how to completely
> reset yum and all of its objects when doing multiple runs w/i a single
> python instance.

While I fully agree about being careful with caches things here are a bit 
different than within the depsolver. These caches can only be outdated when 
the SqliteSack changes. So we probably should clear them in .addDict() and 
.delPackage(). Is there a way to update a SqliteSack object to a newer 
version of the repository? I didn't find any code for that on first sight.

Btw: I want to revisit these caches after the resolveDeps refactoring. 
Performance should be OK then so we can have a look at the memory usage.

> all in all, we can get the ffesti branch committed for something like
> 3.2.3.
Yes, this was the plan from the beginning.

Florian



More information about the Yum-devel mailing list