On Mon, Dec 03, 2007 at 06:08:08PM +0100, Nagy Gabor wrote:
2. this needs sync.c (pmsyncpkg_t) rework, but currently sync.c is so hard-to-understand that I don't want to do this.
If you are referring to your pending sync.c patch, here is the situation : ...
No, I didn't refer to that. But that is still interesting ;-) I just said, that I won't create patch for something which I don't really (want to) understand [that's why sync044.py-fix depends on sync.c-fix in my TODO list] 1. I just said that currently you can use PM_SYNC_TYPE_DEPEND xor PM_SYNC_TYPE_REPLACE (xor PM_SYNC_TYPE_UPGRADE) as sync-type, which prevent us from indicating replace _and_ depend. 2. PM_SYNC_TYPE_REPLACE is also "strange" <- it would be nice if we could copy reason between the _real_ to-be-replaced (util-linux) and replacer packages (util-linux-ng), but replace also indicates conflict resolving, which is a different(?) thing imho. [Replace is simply odd imho, but this is an other story: imho 'pacman -S util-linux-ng' should also offer remove util-linux] 3. I have some transaction problems again, sync creates an upgrade transaction, upgrade transaction creates a remove transaction and it is difficult to follow what and where happens -- 2. is a good example, where the current 'partly done by add.c, partly by sync.c' method doesn't work <- my preferred reason handling would be fully done in sync.c in case of sync transaction [*] 4. There are some other unclear thoughts in my mind: In some cases user want to _replace_ packageB with packageA, however packageA doesn't replace (I mean %REPLACES% here) packageB <- for example packageA and packageB have the same provision, and user want to change... Something similar(?) happens with most conflict resolving, too... And we reached universal transaction again ;-) (see also [*]), maybe one day we can rename-and-merge sync.c to trans.c... These goals (2.) cannot be reached within 2 weeks, and currently %REASON% handling works "somehow" (I overlooked something and I thought that this is totally broken, sorry), so my complaint is reverted. [To be honest, 1. I never like quick-hack bugfixes; and we need a concept first 2. I want to completely rework sync.c where this PM_SYNC_TYPE_DEPEND<->PM_SYNC_TYPE_REPLACE conflict won't be a problem.] Bye PS: If you still want to fix sync044.py only [to be clear: I won't], some pmsyncpkg_t suggestions (again, I don't fully understand sync.c, so be careful ;-): -TYPE_UPGRADE is needless -void ".data" can be renamed to alpm_list_t .replaces, and non-empty replaces simply means the old TYPE_REPLACES (<-so we don't need this synctype neither imho) ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/