improve dependency error message output

[rmarquis]

$ pacaur -S xmp 
:: Package(s) xmp not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for bmp

bmp is a makedep of the dep libxmp. A more explicit error message, such as "no result found for dependency bmp" would be very welcome.

For reference, here is a similar pacman output:

loading packages...
resolving dependencies...
warning: cannot resolve "enemy-territory-data", a dependency of "etlegacy-mod-git"
warning: cannot resolve "etlegacy-mod-git", a dependency of "etlegacy-git"
warning: cannot resolve "enemy-territory-data", a dependency of "etlegacy-mod-git"
:: The following packages cannot be upgraded due to unresolvable dependencies:
      etlegacy-git  etlegacy-mod-git

:: Do you want to skip the above packages for this upgrade? [y/N] 

[Deewiant]

Printing the package(s) that rely on the dependency would be helpful as well. It took me a decent amount of time today to find out which one of my AUR packages was being problematic when all I got was this:

$ pacaur -Sua
:: Starting AUR upgrade...
:: resolving dependencies...
:: no results found for bmp

Something like the following, after the above:

:: (bmp is a dependency of libxmp-VERSION)
:: (libxmp is a dependency of xmp-VERSION)

Or a shorter alternative to replace the no results found:

:: no results found for bmp (needed by xmp-VERSION)

Seeing xmp is most important here because then I know what to --ignore and/or look into fixing.

[rmarquis]

Sounds sexy, but this seems difficult to implement in practice. There is currently no separate tracking of which dependencies are required by a certain installed package, and I believe doing so would complexify the code quite a lot. Instead, maybe a --debug switch that prints every step of the dependency resolution would help?

[Deewiant]

It could narrow it down and I'd definitely welcome the feature, but it's not quite ideal. I'm assuming it'd look similar to the following:

:: looking on AUR for: foo bar baz zot qwer xmp ...
:: looking on AUR for: libfoo libzot qux libxmp ...
:: looking on AUR for: bmp and more stuff ...
:: no results found for bmp

In this case I would've been lucky in that bmp was needed only by a dependency of xmp, so I'd only have needed to go through the missing dependencies of my AUR packages (libfoo libzot qux libxmp ...) to look for which one depends on bmp. Then, associating libxmp with xmp is easy. It could've been worse, though: the dependency could've been called something seemingly unrelated (like qux there), in which case I'd have to also go through my AUR packages one by one to find which of them depends on qux. Similarly, if xmp depended directly on bmp this wouldn't help at all, since it'd just go from "all my AUR packages" to "dependencies, including bmp", which is basically the situation I was already in without this extra output.

[rmarquis]

So I've took time to investigate this issue, and my initial comment is correct: It is not trivial to implement (even on the bash side) since there is no tracking of the dependencies tree at all.

The ideal implementation would return the missing dependency, with the first-level package that needs it (so --ignore could be used effectively).

:: no results found for bmp (needed by xmp-VERSION)

However, at this time I did not succeed in finding any possible implementation that is not overly complex and that is working in all desired user cases.

The implementation depends on the following constraints:

• should not be very verbose, since most of the time this information is useless and duplicates the prompt list,
• should be visible when using the bash side solver, and also the internal (cower) solver. On the long term, it's likely pacaur will switch entirely to the cower solver, depending on upstream enhancement of the AUR interface (see solve dependencies using the RPC interface (AUR 3.0.0) #149).

[rmarquis]

Since it is very complicated to track dependency from the top to bottom, try the other way (bottom up):

• Find which PKGBUILD depends on the missing package (errdep)
• In a loop, check which PKGBUILD depends on the previous package (deps)
• Stop when the package is one that has been inputted (aurpkgs)
• Display the reconstructed dependency tree.

[rmarquis]

The bottom up approach is also delicate to implement, since its heavily depends on the accuracy of the parser. Won't work with complex PKGBUILDs full of bashism... up-to-bottom is the way to go.

[salacio]

I'm getting a similar problem, I'm using peazip-gtk2 as an example, but I've seen this output trying to do a system upgrade. I had installed aura before and used that some also. I got it to install, but after trying the command a few times in a row. The "no results found" output seems to be rather arbitrary.

$ pacaur -Ss peazip-gtk2
aur/peazip-gtk2 5.2.0-1 (63)
    GTK2 archiver utility

% david @ dot in ~ [2:27:42] L:2 N:0
$ pacaur -S peazip-gtk2
:: Package(s) peazip-gtk2 not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for zpaq
:: no results found for balz

% david @ dot in ~ [2:28:21] L:2 N:0
$ pacaur -Ss zpaq && pacaur -Ss balz
community/lrzip 0.616-1
    Multi-threaded compression using the rzip/lzma, lzo, and zpaq algorithms
aur/zpaq 6.43-1 (38)
    Programmable file compressor, library and utilities. Based on the PAQ compression algorithm
aur/zpipe 201-1 (3)
    (De)compress from standard input to standard output using libzpaq
aur/balz 1.15-4 (88)
    Command-line file compressor with a high compression ratio and fast decompression

Also, do you think it might be possible to output the PKGBUILD diffs when upgrading instead of viewing the whole file?

[rmarquis]

@salacio > Works for me. Maybe one of the faulty PKGBUILD has been corrected since your posted?

Also, do you think it might be possible to output the PKGBUILD diffs when upgrading instead of viewing the whole file?

I don't plan to work on this feature, since I consider it out-of-scope of this project.

[rmarquis]

Issue #149 should be implemented first.

[rmarquis]

Check with AUR 3.2.0 and the error return in RPCv3 if there is a clean way to implement this.

[rmarquis]

AUR 3.5.0 and the upcoming pacman 4.2 allow complete static resolution without any needed parsing.

Try reconstructing the dependency tree through the RPC interface, as discussed above (bottom up approach):

• Find which PKGBUILD depends on the missing package (errdep)
• In a loop, check which PKGBUILD depends on the previous package (deps)
• Stop when the package is one that has been inputted (aurpkgs)
• Display the reconstructed dependency tree.

[rmarquis]

This might be easily implemented with the upcoming "--show-build-order" feature of cower.

[brainpower]

I don't know if this is of the same origin the issue mentiond above, so I'll comment here first before opening a new issue.

Today I wanted to do a full update, on some package to be updated, was a new dependency added, attica-git, it conflicts with attica-qt5.
I didn't want to use the -git version so I simply wanted to skip the package which added that dependency.
It would be nice if pacaur could tell me somehow which package wanted that dependency.
Even if its only after I say no to "Remove attica-qt5? [y/N]".
I read above that

There is currently no separate tracking of which dependencies are required by a certain installed package [...]

Does that apply in my situation, too?

% LC_ALL=C pacaur -Sua
:: Starting AUR upgrade...
:: resolving dependencies...
:: looking for inter-conflicts...
:: attica-git and attica-qt5 are in conflict (attica-qt5). Remove attica-qt5? [y/N] n
:: unresolvable package conflicts detected
:: failed to prepare transaction (conflicting dependencies)
:: attica-git and attica-qt5 are in conflict

[rmarquis]

@brainpower > Yes, this is exactly what this issue is about. You'll need to find which dependency needs attica-git and use the --ignore flag with it. This is a really inconvenient, I agree.

Note that you can use pactree -r to learn more about which packages require attica-qt5/-git.

[flying-sheep]

now that we have .SRCINFO, constructing the dependency tree should be much easier.

[rmarquis]

Not really, but since pacaur recently moved to tsort for dependency resolution (#408) I hope I'll find a nice way to achieve this much needed improvement.

[rmarquis]

Initial error tracker implemented in ad7813e. Tsort definitely helped a great deal here!

The output looks like this:

$ pacaur -S plasma-desktop-git
:: Package plasma-desktop-git not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for prison-frameworks (dependency tree: plasma-desktop-git kmenuedit-git khotkeys-git plasma-workspace-git prison-frameworks)

pacaur -S aura                                                                                                                                                                                        
:: Package aura not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for haskell-regex-pcre-builtin (dependency tree: aura haskell-regex-pcre-builtin)
:: no results found for haskell-servant (dependency tree: aura haskell-aur haskell-servant)
:: no results found for haskell-servant-client (dependency tree: aura haskell-aur haskell-servant-client)

This needs some cleaning, and is implemented at the moment for missing dependency only. The --ignore case discussed above still needs to be taken into account.

Feedback welcome!

[Deewiant]

Looks great! The only downgrade I can see is that version bounds are no longer emitted. Using your aura example, pacaur 4.6.10 says:

$ pacaur -Sa aura
:: resolving dependencies...
:: no results found for haskell-regex-pcre-builtin
:: no results found for haskell-aeson<1
:: no results found for haskell-servant-client>=0.9
:: no results found for haskell-servant>=0.9

Note the <1, >=0.9 output. pacaur 4.6.10.91.gad7813e only reports the package names, like you already quoted — and apparently it doesn't report haskell-aeson at all, perhaps because the package itself can be found, just with an unacceptable version number? (I wonder what would happen if that were the only missing dependency?) I think what you have done is definitely an improvement anyway but it'd be even better if it could output the version bounds as well. (Bonus points for reporting "package not found" and "package found but not with right version" differently!)

[rmarquis]

@Deewiant Good catch, I'll have a look shortly.

Edit: regression introduced in 4243d78 and fixed in 11c6663 (see #128). This was actually unrelated to this issue, but current code needs a few adjustment.

[rmarquis]

Fixed in 912ef4c:

$ pacaur -S aura
:: Package aura not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for haskell-regex-pcre-builtin (dependency tree: aura haskell-regex-pcre-builtin)
:: no results found for haskell-aeson<1 (dependency tree: aura haskell-aur haskell-aeson)
:: no results found for haskell-servant-client>=0.9 (dependency tree: aura haskell-aur haskell-servant-client)
:: no results found for haskell-servant>=0.9 (dependency tree: aura haskell-aur haskell-servant)

I do not think a different error message is necessary since all that info is contained in the version number already.

Required package in case of conflicts (only when upgrading) has been implemented in 7e230c5.

[gandalf3]

I'm getting a strange behavior which seems related to this.
Attempting an aur upgrade gives me the following:

:: no results found for python2-qscintilla-qt4<2.10 (dependency tree: virtualbox-ext-oracle python2-qscintilla-qt4)
:: no results found for python2-sip<4.19.1 (dependency tree: virtualbox-ext-oracle python2-sip)
:: no results found for python-qscintilla-qt4-common<2.10 (dependency tree: virtualbox-ext-oracle python-qscintilla-qt4-common)
:: no results found for qscintilla-qt4<2.10 (dependency tree: virtualbox-ext-oracle qscintilla-qt4)
:: no results found for sip<4.19.1 (dependency tree: virtualbox-ext-oracle sip)

There are several things odd about this:

• All the packages and versions which couldn't be found are in the official repos and have satisfactory versions installed already.
• The dependent package (in this case virtualbox-ext-oracle) has seemingly no relation to the packages listed as missing.
• If I manually update the dependent package and run pacaur again, I'll get the same error with another unrelated, but out-of-date aur package in place of virtualbox-ext-oracle. It appears to be going through all outdated aur packages and claiming these five packages from extra are missing dependencies for each of them.

[rmarquis]

@gandalf3 Could you open a new issue with the additional debug output? Thx.