[pacman-dev] Fix reason handling before 3.1 (was: Final steps before 3.1 release)

[Nagy Gabor]

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