[pacman-dev] pacman 3.1 release ?

[Nagy Gabor]

Idézés Nagy Gabor <ngaba at bibl.u-szeged.hu>:

> > On Tue, Sep 04, 2007 at 11:41:50AM +0200, Nagy Gabor wrote:
> > > 
> > > > There are several bugs fixed in 3.1 (mostly fix from Nagy), ...
> > > 
> > > Well, I suggest rewriting _alpm_sync_prepare as soon as possible. You
> > needn't
> > > apply my patch, but the current version is buggy and messy.
> > > Without going into details:
> > > -sync1003.py: you need a more clever checkdeps.
> > > -alpm_checkdeps is called in the beginning of the function, THEN some
> > > hard-to-understand manipulations are done in the target list to resolve
> > > conflicts, and (upgrade) dependencies are not checked again!
> > 
> > But the manipulations done there mostly cause the removal of packages.
> > There may be a particular case where it fails, but I don't really know.
> 
> This is similar to sync1003. It's very dangerous to check deps in the
> beginning
> of the function. If you later remove a package (during conflict resolution
> for
> example) from the target list, you _mustn't_ trust on the first checkdeps
> result
> (the removed package may be needed for an other package in the target list;
> the
> first checkdeps assumed that a local package will be overwritten with the
> removed-from-target package...; checkdeps with TRANS_TYPE_REMOVE won't
> detect
> these!). I don't want to waste more word for this; the _concept_ is buggy.
> 
> > > -removing a package from target list may induce a new conflict (for
> > example: the
> > > old version conflicted, but we assumed that it will be upgraded to a
> > > non-conflicting one; but after we removed the upgrade-package, we got
> the
> > > conflict again)
> > 
> > That case looks a bit odd, but well, I tried to write a pactest for it,
> > but couldn't reproduce this exact situation?
> Semi-pactest file:
> local:
> foo-1.0-1
> bar-1.0-1
> sync: 
> foo-2.0-1 conflicts with bar-2.0-1
> bar-2.0-1 conflicts with foo-2.0-1
> pkg-1.0-1 conflicts with foo-1.0-1 and bar-1.0-1
> User does a pacman -S "foo bar pkg".
> I know, that this is rare, but if pacman will be able to resolve a
> pkglist<->local conflict with remove the package from the target list instead
> of
> removing the local one (why don't we let user decide?), this can happen more
> often.
> 
> > > You can create pactest files to test these.
> > > (IIRC, my patches solve all the problems above.) 
> > > 
> > 
> > But who can? Apparently not me, at least :)

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 ... */.
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?


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