# yay: an AUR helper that resolves dependencies before it builds

> yay is a GPL-3.0 AUR helper written in Go, distributed as yay, yay-bin and yay-git. It wraps pacman, resolves dependencies up front, and asks for all input before any build starts.

**Jguer/yay** — Yet another Yogurt - An AUR Helper written in Go

- Repository: https://github.com/Jguer/yay
- Website: https://jguer.github.io/yay/
- Stars: 13,764 · Forks: 424
- Language: Go
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jguer-yay

## What yay adds on top of pacman

pacman handles the official repositories. It does not search the AUR, fetch PKGBUILDs from it, or track *-git packages that have no version number to compare against. yay fills that gap. The README describes it as "Yet Another Yogurt - An AUR Helper Written in Go", and the feature list is explicit about the scope: dependency solving, PKGBUILD downloading from ABS or AUR, completions for AUR packages, provider selection during search, removal of make dependencies after a build, building local PKGBUILDs with AUR dependencies, and voting on packages.

The audience is Arch users who already know pacman flags. yay reuses them, so `yay -Syu` means what `pacman -Syu` means, except AUR packages are included in the transaction. That reuse is the whole design bet: you do not learn a second command vocabulary. The README's command table shows how far the reuse goes, from `yay -Bi <dir>` for a local PKGBUILD to `yay -G <AUR Package>` for downloading a PKGBUILD without building it.

One consequence is worth stating plainly. Because yay wraps pacman rather than replacing it, anything pacman refuses to do, yay also refuses. If you wanted a package manager with its own database, this is not that.

## Dependency resolution happens before the first build starts

The mechanism the README emphasizes is ordering. yay resolves all dependencies ahead of time and queries the user for all input prior to starting builds. In practice that means the interactive parts (choosing providers, reviewing PKGBUILDs, confirming) are front-loaded into one pass, and the build phase afterwards runs without stopping to ask questions. Anyone who has watched a helper pause mid-transaction for a provider prompt will recognize the difference.

The repository layout matches that description. The top level holds sync.go, get.go, query.go, clean.go, local_install.go and vcs.go, with matching _test.go files beside each. Those names map onto the operations the README documents: syncing and upgrading, fetching PKGBUILDs, querying packages, cleaning unneeded dependencies, building local PKGBUILDs, and handling version control packages. The pkg/ directory holds the supporting code, and cmd.go sits at the root as the command entry point.

Dependency data comes from outside the repository. go.mod lists github.com/Jguer/aur, github.com/Jguer/dyalpm, github.com/Morganamilo/go-pacmanconf and github.com/Morganamilo/go-srcinfo as direct dependencies. dyalpm handles the libalpm side, go-pacmanconf parses pacman configuration, and go-srcinfo parses .SRCINFO metadata. The AUR client and the voting client are separate modules too (github.com/Jguer/votar), which is consistent with the README's note that voting requires AUR_USERNAME and AUR_PASSWORD environment variables.

Configuration is scriptable. go.mod includes github.com/yuin/gopher-lua, and the README's pager answer refers to `yay.opt.pager` in init.lua alongside `pager` in config.json. So there are two configuration surfaces: a JSON file and a Lua file, with environment variables such as PAGER able to override the default.

## Installing yay from source or from yay-bin

The README gives two build routes and one repository route. The source route clones the yay PKGBUILD and builds it with makepkg. The README notes that `sudo` appears in the examples and can be swapped for a different privilege escalation tool.

First install the build prerequisites and clone the PKGBUILD:

```bash
sudo pacman -S --needed git base-devel
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si
```

makepkg -si builds the package and installs it through pacman, so you should end up with a `yay` binary on your PATH. The README also gives a chained one-liner form of the same commands for people who prefer that.

If you would rather not compile yay, the README points at builds generated by GitHub Actions and packaged as yay-bin. The steps are identical except for the clone target:

```bash
sudo pacman -S --needed git base-devel
git clone https://aur.archlinux.org/yay-bin.git
cd yay-bin
makepkg -si
```

On Manjaro or another distribution that packages yay, the README says you can install it directly as root:

```bash
pacman -S --needed git base-devel yay
```

That last route carries a warning in the README: distributions sometimes lag updating yay in their repositories. The AUR badges in the README track three separate packages, yay, yay-bin and yay-git, so the version you get depends on which one you built.

For the first real use, the README describes a one-time step for development packages. If you have *-git packages that were installed without yay, generate the development database once:

```bash
yay -Y --gendb
```

After that, `yay -Syu --devel` checks for development package updates during a system upgrade, and `yay -Y --devel --save` makes that check permanent. Running `yay` with no arguments is an alias for `yay -Syu`.

## Where yay gets in your way

The README documents a failure mode directly, and it is the one most likely to surprise a new user. If a PKGBUILD adds a dependency during installation, yay will not install it. The reason given is architectural: yay resolves all dependencies ahead of time. You are free to edit the PKGBUILD, but the README states that any problems you cause are your own and should not be reported. That is a deliberate trade of flexibility for a build phase that does not stall.

The second constraint is the out-of-date message. yay displays "Flagged Out Of Date AUR Packages" and does not update those packages. The README is clear that this is not a signal that an update exists: it means maintainers flagged the package on the AUR but have not yet updated the PKGBUILDs. If you read that banner as "updates pending", you will wait for something that is not coming.

Third, voting is not self-contained. `yay -Wu` and `yay -Wv` require AUR_USERNAME and AUR_PASSWORD to be set in the environment, per the README. There is no mention of a credential store, so the credentials live wherever you put them.

Fourth, the diff menu is opinionated by default. The README answers the complaint that yay is not asking before editing PKGBUILDs with a single command, `yay --editmenu --diffmenu=false --save`, which implies the default behavior differs from what some users expect. Diffs for all selected packages are collected and shown in one pager session, configurable through `pager` in config.json, `yay.opt.pager` in init.lua, or the PAGER environment variable. If you have not configured a pager and less is unavailable, the README says the fallback is cat, which turns a diff review into a wall of text.

## yay compared with paru, and with plain pacman plus makepkg

The obvious alternative is paru, which appears in this repository's own topic list next to pacaur, yaourt and pacman. Both are AUR helpers that wrap pacman and reuse its flags, so the surface-level difference is small. The difference worth knowing is in the implementation: yay is written in Go and links against libalpm through dyalpm, while the README frames yay's distinguishing behavior as resolving dependencies up front and collecting all user input before builds begin. If you are choosing between them, the question is not which one has more features but whether that front-loaded interaction model matches how you work.

The other alternative is not a helper at all. You can clone a PKGBUILD from the AUR and run `makepkg -si` yourself, which is exactly what the yay installation instructions do. That path gives you complete control and no dependency solver, and it is the right answer if you install AUR packages rarely or want to inspect every step. What you give up is the AUR search, the completions, the combined upgrade transaction, and the *-git update tracking that `yay -Syu --devel` provides.

A third option is the distribution package. On Manjaro and similar distributions, `pacman -S yay` is one command, at the cost of whatever version lag the README warns about.

## Maintenance, upgrades and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-18. The most recent release listed is v13.0.1 from 2026-06-19, following v13.0.0 on 2026-06-17 and v12.6.0 on 2026-06-07. The default branch is `next`, not `master` or `main`, which matters if you are building from a git checkout: the Makefile's MAJORVERSION is 13 and go.mod declares the module as github.com/Jguer/yay/v13, so the branch and the module path are aligned.

Upgrade cost depends on which package you installed. yay-bin and yay-git are AUR packages, so they move with the AUR. A distribution-packaged yay moves at the distribution's pace, and the README warns that pace can lag. The Makefile shows the release tooling: `make release` produces a tarball named yay_${VERSION}_${ARCH}.tar.gz, the Dockerfile builds inside ghcr.io/jguer/yay-builder:latest, and `make docker-release-all` covers armv7h, x86_64 and aarch64. Localization is part of the release: the Makefile lists LANGS including ca, cs, de, es, fr, ja, ru, uk, zh_CN and zh_TW, and the README links to Transifex for translations.

The licence is GPL-3.0, per the LICENSE file and the badge in the README. That is a copyleft licence, which is worth noting if you plan to redistribute a modified yay or link it into another program. This is a factual observation about the licence identifier, not legal advice; if the distinction matters to your organization, have someone qualified read the actual LICENSE file.

## Conclusion

Adopt yay if you run Arch Linux or a derivative and want pacman syntax extended to AUR packages, with dependency resolution and PKGBUILD review handled before any build starts. Do not adopt it if you want a helper that never touches your system config, or if you are on a distribution whose repositories lag behind yay releases; the README itself warns that distributions sometimes lag updating yay. Before you commit, verify three things: that /etc/pacman.conf has the Color option if you expect colored output, that you understand yay -Y --gendb is a one-time command for *-git packages installed outside yay, and that you are willing to read PKGBUILD diffs, because yay resolves dependencies ahead of time and the README states that problems you cause by editing a PKGBUILD are your own.

## FAQ

### Is yay or paru better?

The README does not compare yay with paru, so a verdict is not available from the project's own documentation. What can be said is that both are AUR helpers, both appear in this repository's topic list, and yay's documented approach is to resolve dependencies ahead of time and query the user for all input before builds start.

### What is the yay install command?

The README gives two build routes. For source: sudo pacman -S --needed git base-devel, then git clone https://aur.archlinux.org/yay.git, cd yay, and makepkg -si. For a prebuilt binary, the same sequence with https://aur.archlinux.org/yay-bin.git instead.

### Why is yay not in Pacman?

yay is an AUR helper, and the README's installation section treats the AUR as the primary source: you clone a PKGBUILD and build it with makepkg. The one case where pacman installs yay directly is on Manjaro or another distribution that packages it, where the README gives pacman -S --needed git base-devel yay and warns that distributions sometimes lag updating yay.

### Which distro uses Yay?

yay targets Arch Linux and the AUR, and the README names Manjaro plus other distributions that package yay as places where you can install it with pacman. The README warns that distributions sometimes lag updating yay in their repositories.

## Sources

- [Jguer/yay on GitHub](https://github.com/Jguer/yay)
- [License: GPL-3.0](https://github.com/Jguer/yay/blob/next/LICENSE)
- [Project website](https://jguer.github.io/yay/)
- [README](https://github.com/Jguer/yay/blob/next/README.md)
- [Releases](https://github.com/Jguer/yay/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jguer-yay