seth vidal wrote:
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.
I see this change as a way to increase consistency as it offers a "one size
fits all" solution for searching in sacks. It is also clear that parts of
the API cannot deleted easily. As fixing all callers is not possible there
hopefully is a well defined process of removing/changing parts of the API.
If not it might be a good time to put one in place right now - like raising
DeprecationWarnings for one minor release.
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.
Sorry. I should have stated the goal at the beginning: My goal is increasing
the performance of the resolver by factor 10 for ~1000 pkg operations. I
admit that I should have asked the mailing list if this is really desirable.
May be I just waste my own and everyone else time with something no one
needs or wants...
If there are any ideas to achieve a significant speed up without "cut out
and replace all the code" I am glad to offer my help. But I currently cannot
imagine anything like that.
I agree with you that the patches should go into the development/3.3.X
branch instead of 3.2.X.
Florian Festi
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
