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

Florian Festi ffesti at redhat.com
Wed Aug 1 14:29:57 UTC 2007


seth vidal wrote:
> On Wed, 2007-08-01 at 10:20 +0200, Florian Festi wrote:
>> 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.
> 
> will do. I'll work on getting your patches merged and see what doesn't
> look right from there.

Nice!

>>> 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.
> 
> The other issue is memory use. We're storing some results inside the
> objects which means ballooning memory up some. How much difference does
> this make on a larger transaction?

Current memory usage is not that good. Most of my test cases are around 160 
MB with the first warm up at 190 MB. This is clearly too much - although it 
is slightly better than 3.2.1 (225 MB) which is much better than 3.0.3 (475 
MB). Expect even worse numbers when installing F7 Everything...

With pyrpm we where able to reduce the memory usage below 100 MB and to get 
to 30-60 MB for most sane scenarios. The question of interest is if this is 
also possible with the Python bindings of the rpmlib as I guess a lot of 
memory is used up for the file lists we don't really need. But if we run 
into problems there we can ask Panu for help...


Florian



More information about the Yum-devel mailing list