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 <shiningxc@gmail.com>: listed in data field. This is a nice trick: if you later decide that you won't install "replacer", removing of this syncpkg from target list will automatically revert the induced removal. Conflict resolution also uses this trick. If pkgA conflicts with pkgB, and pkgA is in the target list, then pkgA becomes a replacer (and syncpkg type of pkgA will be _changed_ to PM_SYNC_TYPE_REPLACE, here you will loose information!), and the to-be-removed conflicting local pkgB package will be listed in its data field. See sync.c:567-569, that part (without any further discussion) is wrong. I must mention, that if you give a look at my patch, you will notice, that we needn't use PM_SYNC_TYPE_REPLACE for resolving conflicts (I use it for keeping compatibility.)
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/