yay -U doesn't resolve AUR dependencies

[SleeplessSloth]

Affected Version

yay v10.0.4 - libalpm v12.0.2

Describe the bug
yay -U doesn't resolve AUR dependencies

To Reproduce
Make a PKGBUILD that depends on an AUR package. For example

pkgname='kotatogram-desktop-meta'
pkgver=0.1
pkgrel=1
arch=('any')
license=('GPL')
package() {
        depends=('kotatogram-desktop-bin')
        provides=('telegram-desktop')
}

Expected behavior
I expected yay to install kotatogram-desktop-bin package from the AUR

Output

> makepkg
...
> yay -U kotatogram-desktop-meta-0.1-1-any.pkg.tar.zst 
[sudo] password for user: 
loading packages...
resolving dependencies...
warning: cannot resolve "kotatogram-desktop-bin", a dependency of "kotatogram-desktop-meta"
:: The following package cannot be upgraded due to unresolvable dependencies:
      kotatogram-desktop-meta

:: Do you want to skip the above package for this upgrade? [y/N] 
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'kotatogram-desktop-bin' required by kotatogram-desktop-meta

[grandchild]

pacman -U also doesn't install dependencies. It's a slightly lower-level function, for installing just a package file. Yay shouldn't do what pacman doesn't, given the same flag.

// EDIT: the stuff below doesn't work!

---

And since you're running makepkg before anyway, it has much of the functionality that you want already:

$ man makepkg
[...]
       -i, --install
           Install or upgrade the package after a successful build using pacman(8).
[...]
       -s, --syncdeps
           Install missing dependencies using pacman. When build-time or run-time dependencies are
           not found, pacman will try to resolve them. If successful, the missing packages will be
           downloaded and installed.
[...]
ENVIRONMENT VARIABLES
       PACMAN
           The command that will be used to check for missing dependencies and to install and remove
           packages. Pacman’s -Qq, -Rns, -S, -T, and -U operations must be supported by this
           command. If the variable is not set or empty, makepkg will fall back to ‘pacman’.

So to put that all together, all you need to install an AUR package with automatic dependencies from AUR is to tell makepkg that yay is it's ~father~ PACMAN and then pass the flags -si:

$ PACMAN=yay makepkg -si

[SleeplessSloth]

Awesome, thanks for the help. Seems like I misunderstood the usage of -U

[patatahooligan]

pacman -U also doesn't install dependencies. It's a slightly lower-level function, for installing just a package file. Yay shouldn't do what pacman doesn't, given the same flag.

And since you're running makepkg before anyway, it has much of the functionality that you want already:

$ man makepkg
[...]
       -i, --install
           Install or upgrade the package after a successful build using pacman(8).
[...]
       -s, --syncdeps
           Install missing dependencies using pacman. When build-time or run-time dependencies are
           not found, pacman will try to resolve them. If successful, the missing packages will be
           downloaded and installed.
[...]
ENVIRONMENT VARIABLES
       PACMAN
           The command that will be used to check for missing dependencies and to install and remove
           packages. Pacman’s -Qq, -Rns, -S, -T, and -U operations must be supported by this
           command. If the variable is not set or empty, makepkg will fall back to ‘pacman’.

So to put that all together, all you need to install an AUR package with automatic dependencies from AUR is to tell makepkg that yay is it's ~father~ PACMAN and then pass the flags -si:

$ PACMAN=yay makepkg -si

This doesn't work for me. I always get errors like

==> ERROR: 'yay' returned a fatal error (1): gnome-shell-extension-topicons-plus-git

I suspect that it has to do with makepkg wanting to run it as root, and yay refusing.

[grandchild]

@patatahooligan is right, my explanation doesn't work at all. So this issue still presents an open question of how to build local PKGBUILDs with dependencies in one step.

[patatahooligan]

Here are my findings. I based my tests on my assumption from before that this had to do with yay being run as root. I started with this

PACMAN='sudo -u patatahooligan yay' makepkg

but it gave me

==> ERROR: An unknown error has occurred. Exiting...
zsh: user-defined signal 1  PACMAN='sudo -u patatahooligan yay' makepkg

I haven't figured why but it can't handle the sudo call. No worries, I create a small wrapper

#!/usr/bin/sh
sudo -u patatahooligan yay $@

Running this as PACMAN='yay-wrapper' makepkg -si gives

==> Making package: patatahooligan-dummy-package 2020.09.19-1 (Thu 24 Sep 2020 02:13:17 AM EEST)
==> Checking runtime dependencies...
==> ERROR: 'yay-wrapper' returned a fatal error (1): xfce-superkey-git

With some debugging the source of the error becomes clear. pacman's dependency check pacman -T <packages> returns 127 if any of them is missing, but yay -T <packages> returns 1. This confuses makepkg. So the final solution is

#!/usr/bin/sh

if ! sudo -u patatahooligan yay $@
then
    exit 127
fi

Now finally PACMAN='yay-wrapper' makepkg -si can install an AUR dependency!

Of course this isn't that clean of a solution because translating the error code probably means that you can make other unrelated errors be perceived as missing dependency errors by makepkg so it will mishandle them. Specifically, it will parse yay's output as if it were the list of packages that need to be installed but in case we had an unexpected error, yay's output might contain something that isn't a package name. And if I'm reading this right, makepkg doesn't even use -- to separate package names from pacman flags, which means it could interpret something in yay's output as a flag and do something unexpected.

Therefore, at the very least I believe yay has to match pacman's return value of 127 for this case to be well supported.

EDIT: to be clear, I know that I can only translate 1 to 127, I just don't see in the manual if that is guaranteed to be returned only in case of missing dependencies. If it is, then it's annoying that it doesn't match but it's at least workable.

Although not as crucial, I would also appreciate if someone would figure out how to make sudo work inside the PACMAN variable so that I don't have to use this awkward script at all. EDIT: upon further testing, I'm fairly confident that makepkg cannot handle anything other than an executable name with 0 arguments. It uses type -P to resolve the path of the given binary, which doesn't expect arguments, and even if that worked, it uses quotes when substituting the command, so the whole string is treated like a command which obviously fails.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.