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

I wanted 1Password on my Arch laptop. It is not in pacman’s repositories.
That one sentence contains most of what this post covers, because the next
question — where does software actually come from on Arch, then? — has a
three-part answer: pacman, the Arch User Repository, and optionally a helper
like yay that ties them together.

The three layers

pacman — the package manager and its repositories

pacman is Arch’s package manager. Its packages come from the official
repositories — core, extra, and friends — which are curated by Arch’s
packagers. Everything in them arrives as a signed binary: someone already
compiled it, and pacman verifies signatures against keys in your keyring
before installing. pacman also owns a database of every file it installed,
which is why removal is clean and why you can always answer “which package
owns /usr/bin/foo?”

The official repos are large but deliberately finite. Curating has a cost,
and anything proprietary, fast-moving, or niche tends not to make the cut.
1Password — a proprietary password manager — is exactly that kind of
software.

The AUR — recipes, not packages

The Arch User Repository is not a repository of packages. It is a
repository of recipes, called PKGBUILDs: small shell scripts that declare
where the source comes from, how to verify it, and how to assemble a real
pacman package from it. Community members write them; nobody officially
reviews them.

This distinction — recipes versus binaries — is the single most useful thing
to understand about the AUR. Nothing in the AUR ever bypasses pacman’s
database. Instead:

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

The AUR extends pacman’s reach without weakening pacman’s bookkeeping. Its
coverage is enormous precisely because recipes are cheap to write: when a
vendor ships an official tarball — as 1Password does for Linux — repackaging
it for Arch can be a few dozen lines.

Trust, however, transfers differently. An official repo binary was compiled
by Arch under signed infrastructure. An AUR recipe is executed on your
machine, with your privileges, before any signature check on the final
artifact. The PKGBUILD is the attack surface, which leads to a rule I’ll
come back to: read it.

yay — automation over the recipe workflow

Doing that dance by hand means: find the package on aur.archlinux.org, clone
its git repo, read the PKGBUILD, run makepkg, then pacman -U the result
— and repeat all of it whenever upstream updates. yay automates the chain:
same search, same clone, same build, but driven by pacman-compatible commands
(yay -S, yay -Syu) that reach both tiers at once.

yay is itself community software — the Arch project supports pacman and
makepkg, and explicitly does not support AUR helpers. That “unsupported”
label matters less than it sounds (thousands of people run yay) but it should
be stated rather than discovered during an outage.

The bootstrap problem

Here is the part most guides get wrong. You cannot install yay with pacman,
because yay is not in the official repositories. Several popular guides
claim sudo pacman -S yay works; checking archlinux.org’s package database
directly, the only match for “yay” is ruby-yard (“The Y stands for Yay!”).
I believed the guides for about a minute before verifying, and the lesson is
the one this blog keeps relearning: check the vendor, then the tutorial.

So the first AUR package of your life is built by hand — including the AUR
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

I use yay-bin (upstream’s prebuilt binary) rather than building yay from
source: seconds instead of a Go toolchain compile. The tradeoff is that a
major pacman upgrade can break the prebuilt binary until upstream catches up;
if that ever happens, the fix is building source yay once, the same way.

After that one manual bootstrap, everything else can be declared and
automated.

When to choose which

Two habits make the AUR safe enough to use:

1. Read the PKGBUILD before adopting a package — once at adoption time,
   properly. Popularity is not review: long history and high vote counts did
   not stop the malicious-package wave Arch disclosed in June 2026, which was
   pushed through adopted and well-liked packages.
2. Let signature checks do their job. Good recipes verify the upstream
   source cryptographically. 1Password signs its tarball; makepkg checks that
   signature against your GPG keyring during every build, even unattended
   ones.

What my setup does

My dotfiles repo declares packages in a YAML file, split into two tiers that
mirror the two sources: everything except the aur: group goes through
pacman; the aur: group goes through yay. Keeping the tiers separate means a
failing AUR build can never mask a repository problem, and the install script
can name the right tool in each error message.

Three details earned their place the hard way:

• Updates need the helper, forever. pacman’s -Qu never lists foreign
  (AUR) packages, so without running yay -Syu periodically, an installed
  AUR app silently freezes at whatever version it was. For a password
  manager, “frozen” is the worst possible property. This — not convenience —
  is the argument that finally justified adding a third-party helper.
• The signing key expires before the docs admit. 1Password publishes the
  key its tarballs are signed with; when it rotated, builds started failing
  at the validity check, which looks like a corrupt download but isn’t.
  Importing the current public key fixes it. Trap: expired signing key fails
  the check, not the download — suspect the key before suspecting the
  network.
• Unattended installs skip human review on purpose. My script passes
  --noconfirm --answerdiff None, which suppresses yay’s prompts — including
  the “here is the PKGBUILD diff” review step. That is acceptable only
  because habit #1 happened once, deliberately, at adoption time, and because
  the signature check still runs every build. Automate the repeat, never the
  decision.

The full rebuild walkthrough lives in the Arch runbook;
this post is the conceptual map behind one corner of it.