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
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
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 :)
pacman-dev mailing list firstname.lastname@example.org http://archlinux.org/mailman/listinfo/pacman-dev