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 funtions. Benefits: -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/