Solver errors should be made more explicit

[rmarquis]

When the solver fails for some reason, the error message should help to locate the error quickly in order to ease manual intervention.

Consider the following:

$ auracle buildorder plasma-git-meta
no results found for botan-1.10
BUILD kde-gtk-config-git
BUILD extra-cmake-modules-git
BUILD kconfig-git
BUILD kcoreaddons-git

.. (~100 other dependencies) ...

BUILD plasma-mediacenter-git
BUILD kwallet-pam-git
BUILD plasma-git-meta

Indeed, finding the package that requires the faulty botan-1.10 dependency is not trivial.

A similar issue exists when using auracle download -r plasma-git-meta, but using grep to locate the faulty PKGBUILD can be used as a workaround.

Note that here I'm using plama-git-meta as I know this package chain is currently broken. It has a lot of AUR deps and is a somewhat extreme case, but a similar and much more common case is updating (sync) with multiple AUR outdated packages, with one of the dependency broken for some reason.

A better solution is to have a more explicit error message.

This is what I implemented in pacaur, with these objectives:

• make it easy to locate the faulty PKGBUILD
• determine which is the target requiring that dependency, so it can be --ignored allowing the update of the others packages
• instead of stopping at the first detected error, find all errors at once then stops

$ pacaur -S plasma-git-meta
:: Package plasma-git-meta not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for botan-1.10 (dependency tree: plasma-git-meta plasma-nm-git qca-qt5-git botan-1.10)

Here we see that it is qca-qt5-git that requires botan-1.10, and qca-qt5-git is a second level dependency of the plasma-git-meta target.

The implementation is as follow:

for each erroneous dependency detected
  * check the previous dependency in the topologically sorted buildorder chain
  * if the (erroneous) dependency is a dependency of that package
       store that dep
       recurse with the new dependency
    else
       check the previous element in the buildorder chain 
  * stop when the dependency is a target and print the list of stored deps in the error message

This is somewhat slow, and maybe not robust enough, but gives good results in the majority of cases.

I'm not sure if finding the target requiring the faulty dependency is in the scope of auracle, but printing at least the direct faulty dependency could prove to be very useful for auracle users.

[AladW]

In particular, if a dependency is not found the exit code is 0. Even the current behavior with an exit code greater than 0 may be helpful.

[falconindy]

Generally agree with this. The current implementation of buildorder was based on some opportunistic code reuse with the recursive download code for the sake of getting something that vaguely works. I see now that I'll need to unravel these a bit and go with a callback approach.