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.