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

[seth vidal]

On Wed, 2007-06-06 at 15:10 +0200, Florian Festi wrote:
> 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.

Except we do need to retain some consistency. We've got a lot of diverse
callers of the yum module these days. We can't count on being able to
track all of them down and fix them anymore.


> 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?


 Maybe I'm missing something about the point here - but is your goal to
just cut out and replace all the code currently in yum with new and
as-yet untested code? B/c I'm having a hard time understanding why we
would want to do this inside 3.2.X.

-sv