[RFC] rpmUtils.updates with package objects (Was: Re: [Yum-devel] beyond 3.0.X)

seth vidal skvidal at linux.duke.edu
Mon Dec 11 06:07:47 UTC 2006


On Sat, 2006-12-09 at 19:59 -0500, James Bowes wrote:
> Hi:
> 
> seth vidal wrote:
> > rpmUtils.updates could possible be converted over to pkg objects and/or
> > that whole piece of code be brought into the yum module hierarchy and
> > cleaned up. I understand why it was originally in rpmUtils, that was
> > when I had some delusion that other tools would use rpmUtils but not the
> > yum modules. As it seems now no one uses the rpmUtils unless they're
> > using yum so there's no eventual reason why we shouldn't trundle pieces
> > over to yum as a migration/update path w/o breaking the older mechanism
> > simply by letting it sit.
> 
> Attached is a first cut at replacing package tuples with objects in 
> rpmUtils.updates. This patch breaks the API in ways that will make 
> Jeremy cry, so the next step is to probably make a new file in yum/ for 
> this new updates code, and leave the rpmUtils one alone. Also, to make 
> new methods on the sack objects, instead of modifying the existing ones.
> 
> After that, this code is really slow. For example running
> 'PYTHONPATH=. time python yummain.py -C list updates'
> with one update available is about three seconds slower with the new 
> code than the old code.
> 
>  From what I see, the main performance hits come from running sql 
> queries, reading values from the resultsets, and making package objects 
> from the results.
> 
> You may notice that I've added a mechanism to track packages already 
> loaded from the db to sqlitesack. This caching took about a second off 
> of the previously mentioned test, so hopefully adding it to more method 
> calls will help.

Why not just implement the updates mechanism as a method off of yumbase.
Then you don't have to go traipsing around to get what you need and it
should behave more nicely. Not only that, but since we don't have to
convert the results multiple times it should be faster. Also why are we
using the pkgtuple-like interfaces. If we have 3 package objects and we
want to know which is newer we can either do the comparison ourselves or
we can make a ListPackageSack and run returnNewestByName() to get the
results w/o having a special method in the updates routine. 

I don't like the patch you sent b/c it doesn't actually simplify the
code or make it easier to follow. We should be using what's available in
the packageSack and packageObjects to make the code more trivial.

Do you see what I mean?

-sv





More information about the Yum-devel mailing list