AUR dependencies by soname aren't resolved

[DeltaWhy]

When trying to run aur sync swayfx, I get an error about a missing dependency libscenefx.so. This library is provided by scenefx from the AUR but is not resolved by aur-sync. I think the problem occurs because the dependency is specified by the library soname and not by a specific package name.

If I first build scenefx so it's in my local repo but it is not installed yet, aur sync swayfx does resolve it and ask to install it.

If I try to build the same package using yay after I've removed scenefx from my local repo, it does resolve the dependency and asks whether it should build scenefx or scenefx-git from the AUR. I didn't test any other AUR helpers but this shows it should be possible to handle these dependencies.

I was able to reproduce the issue inside a Docker container with both aurutils and aurutils-git, but I haven't looked at other packages which specify dependencies this way to confirm if that's actually the cause.

Please note: swayfx build is currently broken (reported here) if you have wlroots0.16 installed, but that failure happens later on, in meson, and appears to be unrelated. This dependency issue causes it to fail earlier, during dependency checking. See the linked comment for a fix.

aurutils.log

[Earnestly]

The PKGBUILD looks poorly designed by depending on so many libfoo.so virtual packages.

The depends array is intended for package names (including virtual package names) and not file or libs unless those are provided as virtuals by some parent package.

In this case scenefx does provide the virtual package libscenefx.so so it ought to resolve but this is such a weird way of packaging things. I suppose he really wants the versions of libraries to be specific.

[AladW]

The AUR has partial support for provides, in that you can search by provides, but not an info query. yay uses this since some time: Jguer/yay#1856 (Before that, it had a pkgname heuristic that could easily lead to rate limiting.)

So this is effectively a dupe of #1042

[DeltaWhy]

It does look like this is a subset of that more general issue, but it could be a special case. Looking at wlroots as an example, since swayfx depends on a specific version libwlroots.so=12 - that lib version isn't actually specified in the PKGBUILD (and isn't the same as the package version): https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots/-/blob/main/PKGBUILD?ref_type=heads#L42

But the version info is there in provides in the built package - if I run pacman -Qi wlroots I do see Provides : libwlroots.so=12-64. So it seems like there's some special case in makepkg that adds that info, which makes me wonder if it's also special-cased somewhere else. Whatever yay and paru do seems to work though, so it's probably the same as far as search is concerned.

[DeltaWhy]

Actually it looks like yay doesn't handle version specifications properly. paru -S python=3.10.14 tries to install python310, but yay -S python=3.10.14 tries to install python (which is 3.12). The same happens with libwlroots.so=13 which should install wlroots-git but yay wants to reinstall wlroots.

[AladW]

Right now aur-sync doesn't support version specifications on the command-line either (as the AUR RPC does not support versioned queries). Only versioned dependencies from the package metadata is taken into consideration, which includes versioned provides added by makepkg.

[AladW]

Updated #1042 with the point on versioned CLI arguments.