Idézés Nagy Gabor <ngaba@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/