On Sun, May 16, 2010 at 7:33 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
This patch fixes the phonon/qt issue, if all to-be-upgraded packages are explicit targets (ie. only not-yet-installed packages are pulled by resolvedeps). This condition covers the most common situations, for example it should hold with every -Su operation.
After this patch sync405.py passes, but sync406.py doesn't.
The work is inspired by the patch of Henning Garus, thanks for his work: http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010429.html (I moved the alpm_list_diff computation to sync.c in order to compute it only once.)
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
While not the most pretty, this does seem like the best way to fix this without doing tons of extra work. I'm fine with this if others are. Thanks for looking at this.
I agree, this is ugly. I think the old _alpm_resolvedeps() is also ugly because of its parameter-hell. With code restructure, we could move the loop of sync.c to deps.c, and our source-code would be less hackish (now a weakness of resolvedeps is fixed in sync.c). But since _alpm_resolvedeps() is an internal function, I am not sure this is worth the work (however, this work should be straightforward). In addition, I must mention one more thing, that I forget in the commit message: As usual, remove_unresolvable can complicate things. This whole patch assumes that all targets are resolvable (which is the "normal" case). First I thought that the remove_unresolvable case is harmless, but now I am a bit unsure about this: If a target, say foo, is unresolvable, then resolvedeps can't resolve any other target packages that depend on foo (if no other foo satisfiers exists in the sync repos), because local foo is "invisible" in the local database (because of the new list_diff). So this patch somewhat breaks our remove_unresolvable stuff. I can see no other solution (without complicated graph structure): We have to "predict" whether qt will be upgraded or not; if we predict no, then we have the phonon/qt issue, if we predict yes, then we may have the above remove_unresolvable issue. A crucial fact is that pacman (hopefully) never breaks any dependencies, because the checkconflict and checkdeps tasks run _after_ resolvedeps. Resolvedeps is simply "stupid" in some cases, but the next checks will catch its negligence, and the user has to do some manual work. Personally I still prefer the new behaviour, I have never run into remove_unresolvable situation (like most other users), and the new remove_unresolvable issue can be interpreted as a prevention for "-Sy readline" issue. If there is an unresolvable target in the target list (including -Su), the new issue can be interpreted as pacman is too safe, it won't install any targets depending on the problematic targets. So I need new ACKS. :-) NG PS: I hope my explanation about the issue was clear, if needed, I can provide a pactest file...