[pacman-dev] [patch] resolveconflict clean-up

ngaba at bibl.u-szeged.hu ngaba at bibl.u-szeged.hu
Mon Aug 6 05:30:00 EDT 2007

> 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!!

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
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/

More information about the pacman-dev mailing list