Pacman is the package manager of Arch Linux and its derivatives. In Linux package management, it combines two roles that Debian-based systems split between dpkg and APT: it installs and removes local package files, and it resolves dependencies and downloads packages from remote repositories, all through one command-line tool written in C on top of the libalpm library.
Pacman is designed around the rolling-release model, in which there are no distribution versions and the whole system moves forward continuously. Its syntax is terse, its operations are fast, and its behavior assumes that the administrator keeps the entire system up to date at once.
How Pacman manages packages
A Pacman package is a compressed tar archive, today usually with the .pkg.tar.zst extension and Zstandard compression. Besides the files to install, it carries a .PKGINFO file with the name, version, dependencies and conflicts, an .MTREE file with checksums and permissions, and optionally an install script with hooks that run before or after installation.
Pacman keeps two databases. The local database in /var/lib/pacman/local records every installed package and its files. The sync databases in /var/lib/pacman/sync are copies of repository indexes such as core, extra and multilib, refreshed with pacman -Sy. When a package is requested, Pacman reads the sync database, computes the full dependency transaction, downloads the archives into /var/cache/pacman/pkg, verifies them and then extracts them.
Every package is checked against OpenPGP signatures from the distribution’s packagers, managed through pacman-key and the archlinux-keyring package. The policy is set by SigLevel in /etc/pacman.conf, and the default requires valid signatures for repository packages. An outdated keyring is therefore a common reason why an otherwise correct upgrade fails.
Pacman operations and options
Pacman commands consist of one capital operation letter followed by lowercase modifiers. The operation decides which database is involved, and the modifiers refine what happens. The table lists the operations that cover nearly all daily administration.
| Command | Purpose | Typical use |
|---|---|---|
pacman -Syu | Refresh databases and upgrade everything | Regular full system upgrade |
pacman -S pkg | Install from a repository | Add a new program with dependencies |
pacman -U file | Install a local package file | Install a built or downgraded package |
pacman -Rns pkg | Remove with unneeded dependencies and configs | Clean removal of software |
pacman -Ss term | Search the sync databases | Find a package by name or description |
pacman -Qi pkg | Show details of an installed package | Check version, size and install reason |
pacman -Qo path | Find the owner of a file | Trace an unknown file to its package |
pacman -Qdtq | List orphaned dependencies | Find packages that nothing needs |
Pacman tracks an install reason for every package: explicitly installed or installed as a dependency. This flag drives orphan detection, and it can be corrected with pacman -D --asdeps or --asexplicit. Groups such as base-devel and virtual provisions declared with provides let several packages satisfy the same dependency.
Pacman compared with APT, dpkg, RPM and DNF
Pacman differs from other Linux package managers mainly in scope and philosophy rather than raw capability. It is a single tool for both levels of package handling, it uses a simple text-based database rather than a binary one, and it is tuned for a rolling release rather than for stable point releases.
| Tool | Distribution family | Level | Package format |
|---|---|---|---|
| Pacman | Arch Linux and derivatives | Low and high level in one | .pkg.tar.zst |
| dpkg | Debian, Ubuntu | Low level, no dependency resolution | .deb |
| APT | Debian, Ubuntu | High level on top of dpkg | .deb |
| RPM | Fedora, RHEL, openSUSE | Low level, no repository handling | .rpm |
| DNF | Fedora, RHEL | High level on top of RPM | .rpm |
In practice, Pacman is often noticeably faster than DNF or APT for comparable transactions because its metadata is small and its dependency solver is simpler. The trade-off is that it offers no transaction history with rollback comparable to dnf history undo, and it does not support partial upgrades in the way Debian pinning or backports do.
Configuring Pacman and its ecosystem
Pacman is configured in /etc/pacman.conf, while mirror servers are listed in /etc/pacman.d/mirrorlist. A small number of settings have a large effect on daily experience, and the table shows the ones administrators adjust most often.
| Setting | Example value | Effect |
|---|---|---|
| ParallelDownloads | 5 | Downloads several packages at once |
| IgnorePkg | linux | Holds a package at its current version |
| SigLevel | Required DatabaseOptional | Sets signature verification policy |
| CacheDir | /var/cache/pacman/pkg | Location of downloaded archives |
| [multilib] | Uncommented section | Enables 32-bit libraries on x86_64 |
Packages that are not in the official repositories come from the Arch User Repository, which distributes PKGBUILD build scripts rather than binaries. The makepkg tool builds them into ordinary Pacman packages, and helpers automate that step. Because AUR scripts are user-submitted, reviewing each PKGBUILD before building is a basic security practice. pacman hooks in /etc/pacman.d/hooks and the paccache tool from pacman-contrib round out the ecosystem, the latter keeping the cache from growing without limit.
Pitfalls that break Arch systems
Most Pacman problems come from violating the rolling-release assumption that all packages move together. The rule that experienced users repeat most often is that partial upgrades are unsupported, because libraries and the programs linked against them are rebuilt in step.
| Mistake | Consequence | Better practice |
|---|---|---|
Running pacman -Sy pkg | Partial upgrade with broken library links | Use pacman -Syu pkg instead |
| Ignoring a stale keyring | Signature errors block the upgrade | Upgrade archlinux-keyring first |
| Overwriting files with –overwrite | Silent file conflicts between packages | Find the owner and resolve the conflict |
| Never cleaning the cache | Gigabytes of old archives | Run paccache -r periodically |
| Ignoring .pacnew files | Outdated configuration after upgrades | Merge them with pacdiff |
Another frequent mistake is using IgnorePkg for critical packages such as glibc or the kernel for long periods. Holding back one component while the rest of the system advances recreates the partial-upgrade problem in slow motion, so holds should be short and deliberate.
The short version
Pacman is the app store of Arch Linux, but run from a text terminal. When someone asks for a program, it finds it, also fetches every piece that program needs, checks that nothing was tampered with, and puts everything in the right place. When the program is no longer wanted, it removes it cleanly.
The main thing to remember is that Arch Linux updates everything together. Pacman works best when the whole system is upgraded in one step, much like a library replacing an entire shelf of reference books at once so that their cross-references stay correct.
Where it makes a difference
A developer runs Arch Linux on a workstation used for compiling large projects. After two months without updates, a new compiler package is needed. Running pacman -S gcc against old sync databases fails, and a forum answer suggests pacman -Sy gcc, which would have installed a new compiler next to old libraries.
Instead, the developer first upgrades the keyring, then runs a full `pacman -Syu` that downloads about 1.5 GB in parallel with ParallelDownloads set to 5. Afterwards, pacdiff shows three .pacnew configuration files that are merged by hand, and paccache -rk2 frees several gigabytes of old archives. The result is a consistent, fully upgraded system with a working compiler and no broken library links.