Hi! And please don't forget about the PS of http://www.archlinux.org/pipermail/pacman-dev/2007-August/009078.html data field of pmsyncpkg_t is used iff type == PM_SYNC_TYPE_REPLACE now, so we could use (and rename?) that field as replaces in all cases to avoid the
On Wed, Sep 05, 2007 at 12:12:54PM +0200, Nagy Gabor wrote: problem
above, and so pmsyncpkg_t would be a bit nicer (see alpm_sync_pkg_free);-). So PM_SYNC_TYPE_REPLACE is not needed IMHO (we record to the database explicit or depend reason only): (data != NULL) <=> (type == PM_SYNC_TYPE_REPLACE) if you keep my advice.
As always, a pactest and a patch would make it much easier for us to understand. Let me explain (now I can't create pactest, sorry). PM_SYNC_TYPE_REPLACE indicates that install of "replacer" package will induce the removal of packages
Idézés Xavier
But about this syncpkg stuff, I just noticed recently that the universal transaction idea you're mentioning in the reply : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009082.html is the first entry in aaron TODO list : * transaction object should contain two package list (install and remove) instead of a single list of syncpkgs - this should allow us to get rid of that type. This also requires seperate functionality to return a list of "replaces" packages to the front end, so the frontend can handle the QUESTION() stuff in that case
But maybe you already read that before :) Anyway, I already liked this idea, and seeing it there made me more confident :)
Well, I didn't read it ;-) But it's nice to see that Aaron also likes(?) the idea. (If you start thinking about the solution of sync1003.py you won't find too much different solutions neither...) ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/