On Thu, Sep 23, 2010 at 03:43:32AM +0200, Martin Bähr wrote: > actually, after comparing old versions of the code, at least for system > updates, it aparently never did that. > > http://github.com/sgp/PackageKit/blob/6679c05980b5aec8ac8a6f6454c2bddce68c3c14/backends/conary/helpers/conaryBackend.py > is a version from 2008, where it does: > updateItems = self.client.fullUpdateItemList() > applyList = [ (x[0], (None, None), x[1:], True) for x in updateItems ] > updJob = self.client.newUpdateJob() > suggMap = self.client.prepareUpdateJob(updJob, applyList) > restartDir = self.client.applyUpdateJob(updJob) > > which is, as far as i can tell still the same logic today.
OK, good to know. > then it's no wonder i couldn't see anything that would change the logic > in the diffs, but it also means that the memory problem is elsewhere. > maybe (hopefully) in conary itself, because then 2.2 would help after > all Moving to using the new 2.2 interfaces will require significant redesign, though -- you don't want to try to reimplement the conary update code slightly differently. You really want to have the conary PK backend modify the system model (via code in conary that manages the file; pk shouldn't modify the system model file directly) and then hand off to conary to put that model on the system. The whole "updateall" model essentially goes away, in that you never spelunk the system database and run heuristics to decide what the toplevel items are to update; the "updateall" command now just updates the versions in the search path to point to the latest version of each referenced search trove, and then it runs the model just like any other update command. So what should happen is that the pk conary backend maintains the system model and then hands off to Conary at a bit higher level, I think, and we need to work on how to expose that model in the backend so the right thing happens in the UI. The main questions is probably how to show the user what is happening, and I have no clue how PK intends that to work. There's also a local trove cache implemented for the new update model that we should use in preference to the xmlcache; it should be much faster. And there should be no need for a separate service for providing a pre-fetched cache. We have probably already implemented what is needed to fetch that quickly, as part of optimizing the new update model for speed. So that's definitely something to look at. _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
