Pacman Net

[Oswalda Shutte]

The pacman package manager is one of the major distinguishing features of Arch Linux. It combines a simple binary package format with an easy-to-use Arch build system. The goal of pacman is to make it possible to easily manage packages, whether they are from the official repositories or the user's own builds.

Pacman keeps the system up-to-date by synchronizing package lists with the master server. This server/client model also allows the user to download/install packages with a simple command, complete with all required dependencies.

Sometimes there are multiple versions of a package in different repositories (e.g. extra and testing). To install the version from the extra repository in this example, the repository needs to be defined in front of the package name:

A virtual package is a special package which does not exist by itself, but is provided by one or more other packages. Virtual packages allow other packages to not name a specific package as a dependency, in case there are several candidates. Virtual packages cannot be installed by their name, instead they become installed in your system when you have installed a package providing the virtual package. An example is the dbus-units package.

Sometimes a package group will contain a large amount of packages, and there may be only a few that you do or do not want to install. Instead of having to enter all the numbers except the ones you do not want, it is sometimes more convenient to select or exclude packages or ranges of packages with the following syntax:

Pacman can update all packages on the system with just one command. This could take quite a while depending on how up-to-date the system is. The following command synchronizes the repository databases and updates the system's packages, excluding "local" packages that are not in the configured repositories:

Pacman queries the local package database with the -Q flag, the sync database with the -S flag and the files database with the -F flag. See pacman -Q --help, pacman -S --help and pacman -F --help for the respective suboptions of each flag.

The pacman databases are normally located at /var/lib/pacman/sync. For each repository specified in /etc/pacman.conf, there will be a corresponding database file located there. Database files are gzipped tar archives containing one directory for each package, for example for the which package:

Pacman also has some built-in options to clean the cache and the leftover database files from repositories which are no longer listed in the configuration file /etc/pacman.conf. However pacman does not offer the possibility to keep a number of past versions and is therefore more aggressive than paccache default options.

Pacman's settings are located in /etc/pacman.conf: this is the place where the user configures the program to work in the desired manner. In-depth information about the configuration file can be found in pacman.conf(5).

Pacman 6.0 introduced the option to download packages in parallel. ParallelDownloads under [options] needs to be set to a positive integer in /etc/pacman.conf to use this feature (e.g., 5). Packages will otherwise be downloaded sequentially if this option is unset.

For multiple packages use a space-separated list, or use additional IgnorePkg lines. Also, glob patterns can be used. If you want to skip packages just once, you can also use the --ignore option on the command-line - this time with a comma-separated list.

If you have several configuration files (e.g. main configuration and configuration with testing repository enabled) and would have to share options between configurations you may use Include option declared in the configuration files, e.g.:

Pacman can run pre- and post-transaction hooks from the /usr/share/libalpm/hooks/ directory; more directories can be specified with the HookDir option in pacman.conf, which defaults to /etc/pacman.d/hooks. Hook file names must be suffixed with .hook. Pacman hooks are not interactive.

Pacman hooks are used, for example, in combination with systemd-sysusers and systemd-tmpfiles to automatically create system users and files during the installation of packages. For example, tomcat8 specifies that it wants a system user called tomcat8 and certain directories owned by this user. The pacman hooks systemd-sysusers.hook and systemd-tmpfiles.hook invoke systemd-sysusers and systemd-tmpfiles when pacman determines that tomcat8 contains files specifying users and tmp files.

Besides the special [options] section, each other [section] in pacman.conf defines a package repository to be used. A repository is a logical collection of packages, which are physically stored on one or more servers: for this reason each server is called a mirror for the repository.

Repositories are distinguished between official and unofficial. The order of repositories in the configuration file matters; repositories listed first will take precedence over those listed later in the file when packages in two repositories have identical names, regardless of version number. In order to use a repository after adding it, you will need to upgrade the whole system first.

Each repository section allows defining the list of its mirrors directly or in a dedicated external file through the Include directive; for example, the mirrors for the official repositories are included from /etc/pacman.d/mirrorlist. See the Mirrors article for mirror configuration.

Pacman supports package signatures, which add an extra layer of security to the packages. The default configuration, SigLevel = Required DatabaseOptional, enables signature verification for all the packages on a global level. This can be overridden by per-repository SigLevel lines. For more details on package signing and signature verification, take a look at pacman-key.

The problem is usually trivial to solve (although to be sure, you should try to find out how these files got there in the first place). A safe way is to first check if another package owns the file (pacman -Qo /path/to/file). If the file is owned by another package, file a bug report. If the file is not owned by another package, rename the file which "exists in filesystem" and re-issue the update command. If all goes well, the file may then be removed.

If you had installed a program manually without using pacman, for example through make install, you have to remove/uninstall this program with all of its files. See also Pacman tips#Identify files not owned by any package.

Every installed package provides a /var/lib/pacman/local/package-version/files file that contains metadata about this package. If this file gets corrupted, is empty or goes missing, it results in file exists in filesystem errors when trying to update the package. Such an error usually concerns only one package. Instead of manually renaming and later removing all the files that belong to the package in question, you may explicitly run pacman -S --overwrite glob package to force pacman to overwrite files that match glob.

That same error may also appear if archlinux-keyring is out-of-date, preventing pacman from verifying signatures. See Pacman/Package signing#Upgrade system regularly for the fix and how to avoid it in the future.

When pacman is about to alter the package database, for example installing a package, it creates a lock file at /var/lib/pacman/db.lck. This prevents another instance of pacman from trying to alter the package database at the same time.

Firstly, ensure the package actually exists. If certain the package exists, your package list may be out-of-date. Try running pacman -Syu to force a refresh of all package lists and upgrade. Also make sure the selected mirrors are up-to-date and repositories are correctly configured.

It could also be that the repository containing the package is not enabled on your system, e.g. the package could be in the multilib repository, but multilib is not enabled in your pacman.conf.

If /var/cache/pacman/pkg is a symlink, pacman will try to make a directory instead and thus remove this symlink during self-upgrade. This will cause the update to fail. As a result, /usr/bin/pacman and other contents of the pacman package will be missing.

If you have already encountered this problem and broke your system, you can manually extract /usr contents from the package to restore pacman and then reinstall it properly; see FS#73306 and related forum thread for details.

pacman-staticAUR is a statically compiled version of pacman, so it will be able to run even when the libraries on the system are not working. This can also come in handy when a partial upgrade was performed and pacman can not run anymore.

If even pacman-static does not work, it is possible to recover using an external pacman. One of the easiest methods to do so is by using the archiso and simply using --sysroot or --root to specify the mount point of the system to perform the operation on. See Chroot#Using chroot on how to mount the necessary filesystems required by --sysroot.

Note the use of the w flag for interactive mode. Running non-interactively is very risky since you might end up overwriting an important file. Also take care to extract packages in the correct order (i.e. dependencies first). This forum post contains an example of this process where only a couple pacman dependencies are broken.

Make sure that the relevant environment variables ($http_proxy, $ftp_proxy etc.) are set up. If you use pacman with sudo, you need to configure sudo to pass these environment variables to pacman. Also, ensure the configuration of dirmngr has honor-http-proxy in /etc/pacman.d/gnupg/dirmngr.conf to honor the proxy when refreshing the keys.

To recover from this situation, you need to unpack required libraries to your filesystem manually. First find what package contains the missed library and then locate it in the pacman cache (/var/cache/pacman/pkg/). Unpack required shared library to the filesystem. This will allow to run pacman.

c80f0f1006