Ps: Both the old and patched version of sync_prepare have a problem: If conflict resolution induces a replace, we can loose the PM_SYNC_TYPE_DEPEND information!!
Hi! As a hotfix, we could use (and rename to replaces...) the data field of pmsyncpkg_t to store the induced remove always (independently from sync type). ------------ To tell the truth I want to kill pmsyncpkg_t (I discussed its inefficiency earlier), because we don't really need it. I prefer 2 pmpkg_t lists in pmtrans_t: one for upgrade/add and an other one for remove. This would be cleaner, faster and more "uniform" (now trans->packages can be pmpkg_t or pmsyncpkg_t). And in the future we may implement an "universal transaction" to libalpm, so user could select packages both for removal and for upgrade in _one_ transaction (I imagine a nice GUI front-end here... ;-). And this would be a replacement to alpm_upgrade and alpm_remove transactions. (My checkdeps patch does this work in alpm_checkdeps.) Now give a look at pmsyncpkg_t: struct __pmsyncpkg_t { pmsynctype_t type; pmpkg_t *pkg; void *data; }; We can use the reason field (after merging pmsynctype_t to pmpkgreason_t) of pmpkg_t in the upgrade list instead of type, because in sync-pkgcache that field is not used. pkg is just a pointer to an element of the pkgcache (pkg is not duped), we want to keep this only. data contains the old package in case of upgrade (needless, libalpm doesn't use this info; that's why hotfix works) or the list of to-be-removed packages in case of replace (which we could store in the remove list). As I see, the only benefit of pmsyncpkg_t: data field is a "glue" between the to-be-replaced and the replacer packages: if we revert the replace (in conflict resolution for example) then we automatically revert the induced removal too. However, this powerful property is used only in ~alpm_sync_prepare, so this can be implemented internally. Bye, ngaba PS: the universal transaction (commit) would be a big help for cleaning up sync.c too. ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/