[Yum-devel] [Patch] Resolver Performance and Correctness

Florian Festi ffesti at redhat.com
Wed Jun 6 13:10:48 UTC 2007


Jeremy Katz wrote:
> On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote:
>>   * whatProvides/Requires - returns {po -> [matching Ps/Rs]}
>>    * added to PackageSackBase, MetaSack, PackageSack,
>>      YumAvailablePackageSqlite
> 
> For consistency, it'd be better if these also took the aspo argument and
> worked similarly to the rpmdb methods.  And we could potentially make
> things look a little cleaner with a wrapper of whatPoProvides and
> whatPoRequires -- just calling the underlying method with aspo=True.

My point here is that the current return value of 
RpmSack.whatProvides/Requires doesn't make any sense at all. All user within 
yum call .getInstalledPackageObject(pkgtup) right afterwards. And I cannot 
see any reason why that method should not return the pkg objects it builds 
anyway. So IMHO the question is how do we get rid of that method and how can 
we introduce the new ones.

One solution would be to rename all new whatProvides/whatRequires to 
whatPoProvides/whatPoRequires and deprecate RpmSack.whatProvides/Requires.

I very much dislike the idea of fortifying the old interface by introducing 
the aspo parameter everywhere. But in fact that doesn't matter much. Any 
solution we can agree upon is fine with me.

>>    * Depsolver: .whatInNewProvides, .whatInTsProvides, .whatInTsRequires
>>     * rename/move to tsinfo?
> 
> Yeah, the naming doesn't seem entirely right here.  And the ts bits
> probably should be in the tsInfo.  The formatting of the methods is also
> a little off from the normal style used in yum; please don't split

The reason why I didn't move them to tsInfo is that this would require a 
much closer coupling between the tsInfo and the Depsolve(r) as these methods 
need to access to Depsolve.pkgSack and Depsolve.rpmSack. Is that wanted?

Another issue not yet mentioned is Depsolve.whatProvides and 
.doSackFilelistPopulate. They look pretty unnecessary. Can we push that 
functionality down into the SqliteSack? Using a callback if the main app 
really has to care about?

Florian



More information about the Yum-devel mailing list