Package management on Arch: pacman, the AUR, and yay

Arch software comes from three places: pacman and the official repositories, the Arch User Repository (AUR), and a helper like yay that joins them. 1Password, which isn’t in the official repositories, is a useful example throughout.

pacman

pacman installs signed binaries from Arch’s official repositories, such as core and extra. Arch’s packagers build them, and pacman checks each signature before installing. It also records every file it installs, so removal is clean and pacman -Qo /usr/bin/foo names the package that owns a file.

The official repositories are curated, and proprietary software like 1Password usually isn’t in them.

The AUR

The AUR holds recipes, not packages. Each recipe is a PKGBUILD, a short shell script that says where the source comes from, how to verify it, and how to build a pacman package from it. Anyone can write one, and nobody reviews them.

A recipe builds an ordinary package, so nothing from the AUR goes around pacman:

AUR recipe (PKGBUILD)
      │  makepkg builds it
      ▼
a normal pacman package (.pkg.tar.zst)
      │  pacman installs it
      ▼
tracked, owned files in pacman's database

Recipes are cheap to write, which is why the AUR covers so much. When a vendor ships a Linux tarball, as 1Password does, the recipe can be a few dozen lines.

Trust works differently, though. Arch builds an official binary on its own signed infrastructure. A PKGBUILD runs on the local machine, with the user’s privileges, before anything checks a signature on the result. Read it before using it.

yay

By hand, an AUR install means finding the package, cloning its repo, reading the PKGBUILD, running makepkg, and installing the result with pacman -U. Every update repeats all of it. yay runs those steps behind pacman’s own commands, so yay -S and yay -Syu reach the repositories and the AUR at once.

yay is community software. Arch supports pacman and makepkg but not AUR helpers.

Installing yay

yay isn’t in the official repositories, so sudo pacman -S yay fails, whatever some guides say. Searching archlinux.org for “yay” finds only ruby-yard. The first AUR package built by hand is therefore the helper itself:

sudo pacman -S --needed base-devel git   # makepkg and friends
git clone https://aur.archlinux.org/yay-bin.git
cd yay-bin
makepkg -si                              # asks for sudo at the end
cd .. && rm -rf yay-bin

yay-bin is upstream’s prebuilt binary, so it installs in seconds instead of compiling Go. A major pacman upgrade can break it until upstream catches up, and building source yay the same way fixes that.

When to use which

Situation Use
It’s in the official repositories pacman, every time
It’s not, but the vendor ships Linux binaries The AUR, if a maintained recipe exists. Read the PKGBUILD first. 1Password’s recipe is written with the vendor’s help.
It isn’t packaged anywhere The upstream installer or tarball, as a last resort. pacman can’t track its upgrades or remove it cleanly.
It belongs to another ecosystem, like Flatpak or Snap Only for that ecosystem, since each brings its own runtime and sandbox

Two habits make the AUR safe enough:

  1. Read the PKGBUILD when adopting a package. Popularity isn’t review. The malicious packages Arch disclosed in June 2026 were pushed through adopted, well-liked packages.
  2. Keep signature checks on. Good recipes verify the upstream source. 1Password signs its tarball, and makepkg checks that signature on every build, unattended ones included.

Keeping AUR packages current