[pacman-dev] Universal transaction

Nagy Gabor ngaba at bibl.u-szeged.hu
Fri Sep 28 03:58:36 EDT 2007

> As I started thinking about the implementation, I ran into some older
> questions,
> which we haven't discussed yet; but it is necessary to make decisions,
> because
> the they affect the solution of this problem, too.
> 1. Should we resolve target<->target conflicts by removing the package from
> the
> target list?
> I started to like Xavier's opinion ( == no, we shouldn't), because I
> realized
> that if we don't resolve them, then we don't(?) need pmsyncpkg_t struct.
> [my answer: dunno, Xavier: no]
> 2. So shall I kill pmsyncpkg_t struct? 
> [my answer: yes; however, this is a big job; but this is the first step we
> need
> if we want to implement the "universal" transaction; contra: we loose the
> "glue"
> between the replacer and the to-be-replaced packages <- so the real question
> is:
> do we need this glue?]
> 3. %REASON% handling
> [my answer, Xavier: ~Arch-way]
> Bye, ngaba

Now I explain, how I imagine the universal transaction.
There would be only one transaction type (universal, so type is unneeded ;-),
with an install and remove list. There would be 3 type of loadtarget, add (add a
local pkg to the install list), remove (add a localdb entry to the remove list),
sync (add a sync package from the sync repos); and one resolve and one commit
-we can use the current code with few modifications (alpm_*_loadtarget are
almost the same, keeping sync_prepare + my patches is ~enough, sync_commit is
~enough (add_commit and remove_commit would be helper functions))
-this would kill many duplicates in the code
-the difference between -A/-U and -S would disappear: the pkgorigin would be
different only (handled in commit) => resolving dependencies/conflicts would
also work with -A/-U (on request)
-more freedom (to front-end)

Bye, ngaba

SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/

More information about the pacman-dev mailing list