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
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

Reply via email to