Table of Contents
Introduction
Pacman is the package manager used by Arch Linux and most Arch based distributions. It combines a simple command line interface with a powerful dependency resolver and a compact package format. In this chapter you will focus on how to use pacman in practice, how its syntax differs from other package managers, and some pacman specific conventions. Concepts that belong to general package management are not repeated here.
Pacman basics and syntax
Pacman uses a consistent command structure: pacman followed by options and then package names. The most common pattern is:
pacman -<operation><modifiers> package1 package2 ...
The single dash is followed by one or more letters. Each letter is a flag, and you can combine several in a single group. For example, -S is the operation "sync from repositories", and -y is a modifier that refreshes the package database. Together, -Sy means "sync and refresh the database". Using both uppercase and lowercase letters in the same block is common, for example -Syu.
Many pacman commands must be run as root because they change the system. On a typical system you will prefix them with sudo. For example:
sudo pacman -S htop
Pacman has its own manual page, which you can read with man pacman. This describes all operations and options in detail, but beginners usually need only a small subset.
Pacman uses single dash with combined letters for most operations, for example pacman -Syu. Do not write pacman --Syu. The double dash is reserved for long options like --needed or --noconfirm.
Installing packages from repositories
The standard operation with pacman is installing packages from the configured repositories. For this, you use the -S operation, which stands for "sync".
To install a package, run:
sudo pacman -S package_name
Pacman will download the package and all dependencies from the repositories and then install them. Before installation it will show you a summary of what will happen, including any packages that are pulled in as dependencies and any conflicts that must be removed.
You can install several packages at once by listing them:
sudo pacman -S vim git wget
Pacman will install all of them in a single transaction. If one package cannot be installed because of conflicts or dependency issues, the whole transaction fails, which protects your system from partial installs.
Pacman can also install "groups". A group is a logical collection of packages such as a desktop environment or a set of base tools. To install a group, you use the same -S operation:
sudo pacman -S base-devel
Pacman will then show all packages in that group and ask which ones to install. You can accept all, select some, or deselect some. Group handling is one of the features that distinguishes pacman from some other managers that do not expose group installation in this way.
Removing packages
Removing packages with pacman uses the -R operation. The simplest form is:
sudo pacman -R package_name
This attempts to remove only the named package. If this package is still required by others, pacman refuses to remove it and tells you about the conflict. You must resolve the dependency chain first if you really want that package gone.
Often you also want to remove dependencies that are no longer needed. Pacman can track packages that were installed only as dependencies and are no longer required. To remove a package and its orphaned dependencies in one step, you use:
sudo pacman -Rs package_name
The lowercase s here is a modifier that tells pacman to also remove any dependencies that were installed automatically for the package and are no longer required by any other installed package.
If you want to be aggressive and also remove configuration files and possibly other packages that depend on this one, pacman provides additional modifiers such as -Rns and -Rsc. These can affect a lot of packages, so you should always read the summary before confirming. It is common for Arch users to treat -Rns as a "full cleanup" of a specific package, but you should use it only when you are sure that nothing important relies on that package.
Before confirming a removal command, always read the list of packages that pacman will remove, especially when using options like -Rs, -Rns, or -Rsc. It is easy to remove more than you intended if another package depends on the one you are removing.
Updating the package database and system
Pacman maintains a local copy of the repository database. This cache must be updated regularly so that pacman knows about the latest versions available on the servers. The operation for this is -y, which stands for "refresh database".
To just refresh the database, you run:
sudo pacman -Sy
This downloads updated package lists from the configured mirrors but does not upgrade any installed packages. In most cases Arch users do not stop here because Arch is a rolling release distribution, so the normal practice is to refresh and upgrade in one command.
To upgrade all installed packages to their latest versions, you use:
sudo pacman -Syu
Here -S is the sync operation, y refreshes the database, and u upgrades all out of date packages. This is the canonical pacman command for a full system upgrade and is used often on Arch systems.
You can also upgrade only specific packages by naming them:
sudo pacman -S package_name
If a named package is already installed and you call -S with that name, pacman will upgrade it if a newer version exists. If no newer version is found, pacman will report that there is nothing to do.
Some users run pacman -Sy without u in order to sync the database but not upgrade. On Arch based systems this is discouraged because it can create a mismatch between your installed packages and the latest dependency versions in the repository. This situation is often called a "partial upgrade".
On Arch based systems you should avoid partial upgrades. The recommended practice is to run full upgrades with sudo pacman -Syu rather than updating the database alone. A partial upgrade can break dependencies and make packages fail to work.
Searching and querying packages
Pacman has powerful search capabilities built in, which lets you find packages and inspect what is installed. For operations that refer to packages in the repositories, you again use the -S operation. For operations that refer to installed packages, you use the -Q operation, which stands for "query".
To search the repositories for packages whose names or descriptions match a pattern, use:
pacman -Ss search_term
For example, to search for terminal emulators you might run:
pacman -Ss terminal emulator
Pacman prints the repository name, package name, version, and a short description. This search does not require root privileges because it only reads the local database.
To show information about a package from the repositories, including what it provides, dependencies, and optional dependencies, use:
pacman -Si package_name
The capital I here means "info from sync". This is especially useful before installing a package because you can see what other packages it will pull in and what optional features are available.
To work with installed packages, the typical commands are:
pacman -Q to list all installed packages.
pacman -Qi package_name to show detailed information about an installed package.
pacman -Qs search_term to search through installed packages.
pacman -Qdt to show orphaned packages that were installed as dependencies but are no longer required.
From this output, you can decide whether to remove orphaned packages with an appropriate -R command.
Use -S operations for repository queries (like -Ss, -Si) and -Q operations for installed package queries (like -Qs, -Qi). Mixing them up can give confusing results or nothing at all.
Managing package cache and cleaning up
Pacman stores downloaded packages in a cache directory, usually /var/cache/pacman/pkg. Over time this directory can grow quite large because pacman usually keeps multiple versions of each package. This behavior makes it easy to downgrade or reinstall packages without downloading them again, but it also uses disk space.
Pacman itself has limited cleaning options, so for many tasks Arch systems use a helper tool named paccache, which is part of the pacman-contrib package. If it is installed, you can clean older packages while keeping the most recent versions.
To remove all cached versions of uninstalled packages and keep only the most recent three versions of each installed package, you run:
sudo paccache -r
You can adjust how many versions to keep with the -k option. For example:
sudo paccache -rk 1
This keeps only the latest version of each installed package. This removal affects only cached package files, not installed software.
Pacman itself has the -Sc and -Scc options. With sudo pacman -Sc, pacman removes packages from the cache that are no longer installable and not installed, which is a moderate cleanup. With sudo pacman -Scc, pacman removes all cached packages and also asks if you want to remove unused sync databases. This frees the most space but removes your ability to reinstall or downgrade without downloading again.
Because Arch systems often rely on the ability to downgrade a package quickly, it is common practice to keep at least one older version in cache. Completely emptying the cache should be done only when you really need the disk space and understand the trade off.
Handling configuration files and pacnew/pacsave
Pacman treats configuration files differently from regular files. When a package upgrade wants to modify a configuration file that you have edited, pacman will not silently overwrite your changes. Instead, it leaves your current configuration in place and writes the new version to a separate file with the extension .pacnew.
For example, if /etc/someconfig.conf is part of a package and you have changed it, after an upgrade you might see:
/etc/someconfig.conf.pacnew
It is then your responsibility to compare your existing file with the .pacnew version and merge any important changes. Pacman does not perform this merge automatically because it cannot know your intentions. Tools like diff or graphical merge utilities are often used for this purpose.
Similarly, when you remove a package that owns configuration files, pacman may keep those files on disk and rename them with a .pacsave extension. This preserves your configuration in case you reinstall the package later. For example, removing a package might leave:
/etc/someconfig.conf.pacsave
You can then inspect, delete, or reuse that file as you see fit.
After large upgrades, always check for .pacnew and .pacsave files in configuration directories like /etc. Ignoring them can leave you with outdated or incomplete configuration that may not match the new version of the software.
Pacman configuration and mirror selection
Pacman itself is configured primarily via the file /etc/pacman.conf. This file controls which repositories are enabled, how packages are handled, some default options, and other behavior specific to pacman. You usually edit this file as root with a text editor. For example:
sudo nano /etc/pacman.conf
Inside this file you can enable optional repositories, adjust how many package versions pacman keeps, and configure hooks. Because this configuration applies to the whole system, any mistake here can cause pacman to malfunction. It is common to keep a backup copy of the file before making significant edits.
The servers from which pacman downloads packages are listed in a separate file, usually /etc/pacman.d/mirrorlist. This file contains a list of HTTP and HTTPS mirrors, often grouped by country and sorted by speed. Pacman uses this list when syncing and downloading packages. You can change the order or comment out slow mirrors to improve your download performance.
On Arch based systems there are helper tools that can automatically rank mirrors or generate a new mirror list based on speed tests. Regardless of how you manage it, the mirror list is specific to pacman and determines how quickly and reliably you can access the repositories.
Pacman logs and troubleshooting basics
Pacman records all operations in a log file located at /var/log/pacman.log. This is useful when you want to review what packages were installed, upgraded, or removed, and when those actions took place. When troubleshooting a broken package or a failed upgrade, reading this log often reveals exactly which change happened before the problem occurred.
You can view the log with any text viewer, for example:
less /var/log/pacman.log
If a pacman command fails, the error messages are usually clear and tell you if the problem is a conflict, a missing dependency, a locked database, or a network issue. One frequent issue is that another package management process is already running. Pacman uses a lock file, typically /var/lib/pacman/db.lck, to avoid concurrent access to the database. If a previous pacman process crashed, this lock might remain. In such a case you must ensure that no pacman process is active, then remove the lock as root.
Another common scenario is a failed download because a mirror is temporarily unavailable. In that case you can retry the command, switch to another mirror in your mirror list, or regenerate the mirror list.
Understanding pacman specific behavior, such as the use of -Syu for full upgrades, the distinction between -S and -Q operations, and the handling of .pacnew and .pacsave files, prepares you to manage an Arch based system safely and effectively using its native package manager.