[pacman-dev] pacman 3.1 release ?

[Nagy Gabor]

> On Mon, Sep 17, 2007 at 01:26:55PM +0200, Nagy Gabor wrote:
> > OMG, I noticed that current pacman won't resolve target<->target conflict
> (it
> > stops with unresolveable conflict error <- so that ~150 line
> conflict-resolution
> > monster is not so efficient in sync.c ;-). However pacman may still remove
> > packages from the target list: sync.c: /* pacman -S blackbox xfree86 ...
> */.
> 
> Actually, I think that's the only reason why your patch breaks a few
> pactest.
> In case of target <-> target conflicts, pacman used to fail. But after your
> patch,
> it tries to automatically resolve it by selecting one of the target.
> You said that yourself :)
Oh, I remember now, but I thought that those pactests "decide" not to resolve
that conflict [Note: I used the word 'autoresolves' here:
http://www.archlinux.org/pipermail/pacman-dev/2007-August/009078.html];-) And I
never could get myself to read that whole messy part in sync.c, however I saw
that pacman _can_ remove packages from the target list.

> So you broke the pactests that had a target <-> target conflict, and
> expected
> pacman to fail.
> I am still not sure what's the best default behavior (for example, the
> behavior using --noconfirm, which is how pactest are run).
> But in any cases, it's probably better to ask the user (you already said that
> as well).
> 
> > I don't understand that part at all:
> > resolvedeps first search for (blackbox's) dependency satisfiers in the
> target
> > list. So it will find xfree86, if that dep is OK [in this case we don't
> need to
> > remove anything]; if xfree86 dep is not OK, resolvedeps must find and pull
> a
> > real satisfier (xorg), [in this case we cannot remove xorg, because we will
> get
> > a broken dep].
> > Any idea?
> > 
> > 
> 
> See :
> http://www.archlinux.org/pipermail/pacman-dev/2007-July/009041.html
> http://www.archlinux.org/pipermail/pacman-dev/2007-August/009155.html

I would be happy if only the comment would be outdated ;-) Hopefully the whole
part around that comment never runs (otherwise it breaks some depends), so it
can be removed [line 504-554, 577-587(?)].
So the current sync.c is not so dangerous as I thought, however that is very
ugly (IMHO): [asked variable is unneeded, sync1003.py still fails]

Bye, ngaba

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