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


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Idézés Xavier <shiningxc@gmail.com>:

> On Mon, Dec 03, 2007 at 08:26:05PM +0100, Nagy Gabor wrote:
> > > 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]
> >
>
> Ok, so I just think this is another argument for considering the merge of
> your sync.c fix as soon as possible, and this could motivate you to work on
> a fix for sync044 and/or other related things after 3.1 release.
>

Thx, and of course I totally agree with you ;-)

I add an other small issue here: when the current code removes a package from
the target list it also removes the locally installed package (if any), which
can be needless (versioned conflicts, provision-conflicts, etc.) <- but at least
by doing this it avoids appearing new conflicts

Bye


----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev