On Fri, 2007-03-23 at 15:51 +0100, Florian Festi wrote: > I see absolutely no reason why this shouldn't be possible in the search > methods. Of course you would have to move the .inPrcoRange() code into the > package sack. In fact the rpmsack supports just that (whatProvides(), > whatRequires()).
It is possible in the search method, except it'll mean doing the same operation inside the sack anyway. Putting it per-package object means that no matter the type of sack we're using it'll work. I'll be happy to give it a try if it'll help speed things up further. > If the sqlitesack and the transaction (as virtual sack representing the > future rpmdb) provide this interface, too, the resolver will look much > cleaner and changes on 'who searches where' will be much easier. A sack object from the txmbr's in the tsInfo would be useful. I've thought of that, too. However, it seems like we would need to be able to get back a ListPackageSack based on: - ts state - pkg nevra - all I might be able to whip up a simple method to let us interact with it as a PackageSack so we can use the same methods. But that's even more reason the search method needs to be independent of the type of sack it is. -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
