Arch Linux: What Rolling Release Actually Costs

Arch Linux gives you the newest version of everything, continuously, on a system containing only what you chose to install. There is no release to upgrade between and no version number — you update, and you are current. It also has the best documentation in Linux, which is why people who do not run Arch still end up reading its wiki.

The costs are real and this page states them plainly, because most write-ups do not.

What rolling release means day to day

On Debian or Ubuntu, package versions are frozen and change in one large step every few years. On Arch, packages update within days of upstream releasing them. There is no “next release” to plan for, and an Arch system installed in 2019 and updated regularly is the same system as one installed today.

Three consequences follow, and they are the whole trade.

• Breakage arrives in small pieces rather than large ones. Instead of one traumatic release upgrade every two years, you get an occasional awkward update. Most people find this easier. It is still not zero.
• Updating is a task with your attention on it, not a background chore. Arch expects you to read what is changing.
• You cannot leave it alone for six months. A long-neglected Arch system is genuinely harder to update than a neglected Debian one, because so much has moved at once.

The last point is the one that decides whether Arch suits you. It is not that Arch is fragile — a maintained Arch system is very reliable. It is that maintenance is an ongoing commitment rather than an occasional event.

pacman

pacman’s flags are terse and unlike apt or dnf. The four you need are -S (sync, meaning install), -R (remove), -Q (query what is installed) and -U (install a local file).

# Update the entire system. This is THE command.
sudo pacman -Syu

# Install and remove
sudo pacman -S nginx
sudo pacman -Rns nginx          # also removes config and unused dependencies

# Search
pacman -Ss nginx                # in the repositories
pacman -Qs nginx                # among installed packages

# Inspect
pacman -Qi nginx                # details of an installed package
pacman -Ql nginx                # files it owns
pacman -Qo /usr/bin/nginx       # which package owns this file

# Packages nothing depends on any more
pacman -Qtdq
sudo pacman -Rns $(pacman -Qtdq)

# Update the entire system. This is THE command.
sudo pacman -Syu

# Install and remove
sudo pacman -S nginx
sudo pacman -Rns nginx          # also removes config and unused dependencies

# Search
pacman -Ss nginx                # in the repositories
pacman -Qs nginx                # among installed packages

# Inspect
pacman -Qi nginx                # details of an installed package
pacman -Ql nginx                # files it owns
pacman -Qo /usr/bin/nginx       # which package owns this file

# Packages nothing depends on any more
pacman -Qtdq
sudo pacman -Rns $(pacman -Qtdq)

Never run pacman -Sy on its own

This is the one rule that matters, and breaking it is the most common way people destroy an Arch install.

-Sy refreshes the package database without upgrading anything. If you then install a package, pacman fetches the new version of it — built against libraries newer than the ones on your system — while everything else stays old. That is a partial upgrade, and Arch does not support it in any sense. The usual result is a system where things fail with library version errors, sometimes including pacman itself, which makes recovery awkward.

# WRONG - creates a partial upgrade
sudo pacman -Sy
sudo pacman -S somepackage

# RIGHT - refresh and upgrade together, always
sudo pacman -Syu
sudo pacman -S somepackage

# WRONG - creates a partial upgrade
sudo pacman -Sy
sudo pacman -S somepackage

# RIGHT - refresh and upgrade together, always
sudo pacman -Syu
sudo pacman -S somepackage

There is no situation in normal use where -Sy alone is correct. If you are not prepared to upgrade the whole system right now, do not refresh the database either.

The AUR

The Arch User Repository is a collection of build scripts — called PKGBUILDs — contributed by users. It is why almost any piece of software you can name is available on Arch, including things no other distribution packages.

Two things about it are important. The AUR contains build recipes, not packages: your machine downloads the source and compiles it. And nothing in it is reviewed by Arch. A PKGBUILD is a shell script that runs on your machine, uploaded by a stranger.

# The manual way, which shows you what is happening
git clone https://aur.archlinux.org/some-package.git
cd some-package

# READ THIS BEFORE BUILDING. Every time.
less PKGBUILD

makepkg -si

# The manual way, which shows you what is happening
git clone https://aur.archlinux.org/some-package.git
cd some-package

# READ THIS BEFORE BUILDING. Every time.
less PKGBUILD

makepkg -si

Most people use a helper such as yay or paru, which makes AUR packages feel like repository packages. That convenience is also the risk: it makes it easy to install and update AUR packages without ever reading what they do. Helpers show you the PKGBUILD by default — read it, at least the source= line and any prepare() or install functions.

# Install yay (itself from the AUR, built manually the first time)
sudo pacman -S --needed git base-devel
git clone https://aur.archlinux.org/yay.git
cd yay && makepkg -si

# Then, day to day
yay -Syu                # repositories and AUR together
yay -S package-name
yay -Qua                # which AUR packages have updates

# Install yay (itself from the AUR, built manually the first time)
sudo pacman -S --needed git base-devel
git clone https://aur.archlinux.org/yay.git
cd yay && makepkg -si

# Then, day to day
yay -Syu                # repositories and AUR together
yay -S package-name
yay -Qua                # which AUR packages have updates

Keep AUR use deliberate. A handful of packages is fine; forty of them is a maintenance burden, because each one is a separate volunteer who may lose interest, and AUR packages are the usual reason an update stops working.

Updating safely

Arch occasionally requires manual intervention during an update — a configuration format changes, or a package needs replacing by hand. These are announced on the front page of archlinux.org, and the announcement is the difference between a five-minute task and a broken machine.

1. Check the Arch news before a large update. Subscribing to the RSS feed costs nothing; informant from the AUR will block an update until you have read outstanding items.
2. Update the whole system, never part of it. sudo pacman -Syu.
3. Do not update just before you need the machine. Not because it usually breaks, but because when it does you want time.
4. Handle .pacnew files. When a package ships a new default config and you have edited yours, pacman leaves the new one alongside as .pacnew rather than overwriting. Ignoring these for a year is how you end up running a configuration that no longer matches the software.
5. Keep the package cache pruned, but keep a few versions — downgrading to yesterday’s package is how you recover from a bad update.

# Find configuration files awaiting a merge
sudo pacdiff

# Prune the cache, keeping the last 3 versions of each package
sudo paccache -rk3

# Roll back to a cached older version
sudo pacman -U /var/cache/pacman/pkg/package-1.2.3-1-x86_64.pkg.tar.zst

# Find configuration files awaiting a merge
sudo pacdiff

# Prune the cache, keeping the last 3 versions of each package
sudo paccache -rk3

# Roll back to a cached older version
sudo pacman -U /var/cache/pacman/pkg/package-1.2.3-1-x86_64.pkg.tar.zst

The genuinely robust safety net is snapshots. On Btrfs with snapper or timeshift-autosnap, a pre-update snapshot means a broken update is a reboot away from being undone. If you plan to run Arch as a daily machine, set this up on day one rather than after the first bad afternoon.

Installing it

Arch has no graphical installer in the usual sense. You boot a live image and build the system by hand: partition the disk, format, mount, pacstrap the base packages, generate an fstab, set locale and time zone, install a bootloader.

There is now an official guided installer, archinstall, which does all of that from a menu in about ten minutes and is a legitimate way to install Arch. But doing it manually once is the best Linux education available — you finish it understanding what a bootloader does, why fstab exists, and what a distribution actually assembles on your behalf. The official installation guide is the reference, and it is excellent.

Either way, what you get afterwards is a command line and nothing else. No desktop, no browser, no network manager unless you installed one. That is the design.

The wiki

The ArchWiki is the best technical documentation in the Linux world and it is not close. It is accurate, current, unusually detailed, and it covers configuration rather than just installation. Most of it applies to any distribution — the systemd, networking, audio and hardware pages are worth reading whatever you run.

If you take one thing from this page without ever installing Arch: when you have an obscure hardware or configuration problem, search the ArchWiki before anything else.

Things that catch people out

The keyring one is worth remembering because it is confusing the first time: if a system has been idle a while, the signing keys have rotated, and you must update the keyring package before anything else will verify.

Who should run Arch

Yes, if you want to understand how a Linux system fits together, you enjoy configuring things, and you will actually update regularly. It is also a strong choice for gaming and for very new hardware, since kernel and driver updates arrive within days rather than years — which is exactly why the Steam Deck runs an Arch derivative.

Not, if:

• It is a server. Arch on a production server is a poor fit — unattended updates on a rolling release is precisely the wrong combination. Use Debian, Rocky or Alma.
• It is a machine other people depend on and you are the only one who can fix it.
• You want to install something and not think about it again for two years.
• You are new to Linux. Not because you could not manage it, but because when something breaks you will not yet have the vocabulary to describe what happened. Six months on Ubuntu or Fedora first makes Arch far more rewarding.

Worth knowing: EndeavourOS and Manjaro offer Arch with a graphical installer and sensible defaults. EndeavourOS stays close to Arch and uses its repositories directly. Manjaro holds packages back for a couple of weeks for testing, which sounds safer but interacts badly with the AUR, since AUR packages are built against current Arch. If you want easier Arch, EndeavourOS is the less surprising of the two.

Quick reference

Related reading

• Debian — the opposite philosophy, and the right answer for servers
• Fedora — current software with more safety rails
• Ubuntu — where most people should start
• Package management — pacman next to apt and dnf
• Disks and mounting — useful before a manual Arch install
• Command line basics — the assumed starting point