[pacman-dev] [PATCH] Partial fix for the phonon/qt issue
ngaba at bibl.u-szeged.hu
Mon May 17 15:17:38 EDT 2010
> On Sun, May 16, 2010 at 7:33 PM, Nagy Gabor <ngaba at 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 at 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. :-)
PS: I hope my explanation about the issue was clear, if needed, I can
provide a pactest file...
More information about the pacman-dev