[pacman-dev] pacman 3.1 release ?

[Nagy Gabor]

Idézés Xavier <shiningxc at gmail.com>:

> On Wed, Sep 05, 2007 at 12:12:54PM +0200, Nagy Gabor wrote:
> > 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
> 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
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/