Add versioned dependency support

[rmarquis]

From the bug reports I've collected in the pacaur tracker over the years, I'd say the majority of edge cases are due to AUR versioned dependencies. Checking for version in addition to names for AUR dependencies would avoid these situations.

I've looked into the sources, and my current understanding is that versioning check is implemented in a similar fashion as done in cower with only a name check (please correct me if I'm wrong here).

For example, a few months ago there was a bug in bauerbill, with the ros-indigo-desktop-full package. While aurutils was able to "solve" the tree, it wasn't able to find what was causing the error since it doesn't implement version check either. I simply ran pacaur to pinpoint the issue:

$ pacaur -S ros-indigo-desktop-full
:: Package ros-indigo-desktop-full not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for sdformat>=4.2.0

Quickly looking at the AUR revealed that only sdformat 4.1.0 was available (this particular issue has been solved since then, though that package deps chain is still broken due to another missing dep).

Most of the time these versioning issues are due to completely unneeded versioning deps in the PKGBUILDs, but it is useful to detect them to make it easy to fix them. There are also a few entirely valid cases (see f.e. https://github.com/falconindy/cower/issues/91, admittedly one of the most complex case I've ever seen).

The drawback of doing versioning check is that it is a bit slower to process (and sometime much slower as implemented in bash in pacaur), but ensuring a build chain won't be broken before starting the build processs is quite important.

See also aurutils/aurutils#10 for a relevant discussion.

[AladW]

I've filed a bug report for the AUR to support querying versioned package names:

https://bugs.archlinux.org/task/54906

[E5ten]

Even though versioned depencency support will need the AUR to support querying versioned package names (at least it seems that way) would it be possible for a flag to be added to buildorder to output the versioning string on versioned deps in the buildorder so that the user could check versioned dependencies that are in the buildorder output but otherwise rely on buildorder?

[Morganamilo]

Honestly I don't think proper versioned dependency would be too hard seems as we have access to vercmp via alpm.

[falconindy]

Well no, it is that difficult because dependencies don't always match the name -- that's the crux of the issue here. Cases where the dependency matches the package name exactly either Just Works™ (because there can only be one package by that name) or you have an unbuildable package because the AUR package is out of date or strictly incompatible with the Arch package landscape.

Example: you might have a package in the repositories called libfoo, and an AUR package called libfoo-unstable which provides a newer version (i.e. provides=(libfoo=x.y.z)). If an AUR package depends on libfoo>=x.y.z which can only be satisfied by libfoo-unstable, how do you resolve this? The AUR needs functionality similar to libalpm's alpm_find_satisfier that allows searching for dependencies by a depstring which may or may not match a package by that exact name.

[Morganamilo]

Finding all satisfies and versioned dependency support are totally different issues imo.

[falconindy]

Please describe a case where having some form of versioned dependency support is useful without full depend (provider) resolution.

[Morganamilo]

If for some reason a package depends on foo=1 but now foo has been upgraded to foo=2. This is going to fail to build but auracle won't tell you this.

auracle is the easiest place to implement this seems as you have access to alpm_depend_t and vercmp.

[falconindy]

Yes, I described that case. I don't think it's very useful/interesting because all it represents is an out of date or mothballed AUR package. There should never be a healthy package in this situation.

[Morganamilo]

Yes there shouldn't be but it happens.

[falconindy]

Sorry, making a half attempt at fixing the dependency solver just to handle infrequent cases of broken packages isn't something I have interest (or time) to tackle.

I'll fix this once the AUR actually has the support that we need to do this properly.

[Morganamilo]

Alright then, fair enough.

[falconindy]

2 weeks ago I hadn't looked at the new REST API that apparently now exists and allows querying by "provides". That's 80% of the way there. Auracle can now do a more thorough job of finding dependencies when the names don't directly match. However, versioned dependency support is still lacking. One could potentially do something like:

• filter out packages provided by the repos
• query for remaining dependencies, leaving some subset unresolved
• query for remaining unresolved dependencies by unversioned provides
• post-hoc filter those results through alpm_pkg_vercmp to discard unsatisfiable packages

Note that the two queries here could be done in parallel, albeit a bit wastefully, or serially, at the cost of performance. Not yet clear which of those approaches results in easier to read code.

[falconindy]

So d36d317 was an easy patch to write and gives us dependency resolution. Thinking about adding this to download or buildorder verbs seems substantially more complicated. If/when you encounter a dependency that has to be solved by a provider, how do you present the options?

1. Make the selection interactive. Hard pass on this.
2. Present all the options. Seems obvious, but how do you proceed with the build order in this case? It would be ill-advised to traverse them all to come up with the deps for all the possible providers.
3. Come up with some heuristic to pick one. Most votes? Most popular? Random? I don't know, but this surely wouldn't be flexible enough for general use.
4. Present the unresolved provider "stub", let the caller figure it out through the new resolve verb.

Honestly, option 4 seems like the best, but I'm open to other ideas.

[rmarquis]

Option 4 also seems like the best option to me. As long as the output in buildorder makes it clear that an explicit choice needs to be made, that should be more than fine. I can't think of a better alternative (and option 3 just seems the worst to me).

(also thanks to you for working on that old ticket - I'm still enjoying auracle after all these years).