List all installed packages that are not in the specified repository repo_name

$ comm -23 <(pacman -Qtq | sort) <(pacman -Slq repo_name | sort)

List all installed packages that are in the repo_name repository:

$ comm -12 <(pacman -Qtq | sort) <(pacman -Slq repo_name | sort)

Listing files owned by a package with size

This one might come in handy if you have found that a specific package uses a huge amount of space and you want to find out which files make up the most of that.

$ pacman -Qlq package | grep -v '/$' | xargs du -h | sort -h

Identify files not owned by any package

If your system has stray files not owned by any package (a common case if you do not use the package manager to install software), you may want to find such files in order to clean them up. The general process for doing so is:

Create a sorted list of the files you want to check ownership of:

$ find /etc /opt /usr | sort > all_files.txt

Create a sorted list of the files tracked by pacman (and remove the trailing slashes from directories):

$ pacman -Qlq | sed 's|/$||' | sort > owned_files.txt

Find lines in the first list that are not in the second:

$ comm -23 all_files.txt owned_files.txt

This process is tricky in practice because many important files are not part of any package (e.g. files generated at runtime, custom configs) and so will be included in the final output, making it difficult to pick out the files that can be safely deleted.

Tip: The lostfilesAUR script performs similar steps, but also includes an extensive blacklist to remove common false positives from the output. aconfmgr (aconfmgr-gitAUR) also allows tracking orphaned files using a configuration script.

Removing unused packages (orphans)

For recursively removing orphans and their configuration files:

# pacman -Rns $(pacman -Qtdq)

If no orphans were found, pacman errors with error: no targets specified. This is expected as no arguments were passed to pacman -Rns.

Note: The arguments -Qt list only true orphans. To include packages which are optionally required by another package, pass the -t flag twice (i.e., -Qtt).

Removing everything but base group

If it is ever necessary to remove all packages except the base group, try this one liner:

Listing changed backup files

If you want to backup your system configuration files you could copy all files in /etc/, but usually you are only interested in the files that you have changed. Modified backup files can be viewed with the following command:

# pacman -Qii | awk '/^MODIFIED/ {print $2}'

Running this command with root permissions will ensure that files readable only by root (such as /etc/sudoers) are included in the output.

Back-up the pacman database

The following command can be used to back up the local pacman database:

$ tar -cjf pacman_database.tar.bz2 /var/lib/pacman/local

Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.

The database can be restored by moving the pacman_database.tar.bz2 file into the / directory and executing the following command:

# tar -xjvf pacman_database.tar.bz2

Note: If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult #Restore pacman's local database.

Tip: The pakbak-gitAUR package provides a script and a systemd service to automate the task. Configuration is possible in /etc/pakbak.conf.

Check changelogs easily

When maintainers update packages, commits are often commented in a useful fashion. Users can quickly check these from the command line by installing pacologAUR. This utility lists recent commit messages for packages from the official repositories or the AUR, by using pacolog <package>.

2. Edit pacman.conf and add this repository before the other ones (e.g. extra, core, etc.). This is important. Do not just uncomment the one on the bottom. This way it ensures that the files from the CD/DVD/USB take precedence over those in the standard repositories:

3. Finally, synchronize the pacman database to be able to use the new repository:

# pacman -Syu

Custom local repository

Use the repo-add script included with pacman to generate a database for a personal repository. Use repo-add --help for more details on its usage. To add a new package to the database, or to replace the old version of an existing package in the database, run:

Note: A package database is a tar file, optionally compressed. Valid extensions are “.db” or “.files” followed by an archive extension of “.tar”, “.tar.gz”, “.tar.bz2”, “.tar.xz”, or “.tar.Z”. The file does not need to exist, but all parent directories must exist.

The database and the packages do not need to be in the same directory when using repo-add, but keep in mind that when using pacman with that database, they should be together. Storing all the built packages to be included in the repository in one directory also allows to use shell glob expansion to add or update multiple packages at once:

$ repo-add /path/to/repo.db.tar.gz /path/to/*.pkg.tar.xz

Warning: repo-add adds the entries into the database in the same order as passed on the command line. If multiple versions of the same package are involved, care must be taken to ensure that the correct version is added last. In particular, note that lexical order used by the shell depends on the locale and differs from the vercmp ordering used by pacman.

repo-remove is used in the exact same manner as repo-add, except that the packages listed on the command line are removed from the repository database.

Once the local repository database has been created, add the repository to pacman.conf for each system that is to use the repository. An example of a custom repository is in pacman.conf. The repository's name is the database filename with the file extension omitted. In the case of the example above the repository's name would simply be repo. Reference the repository's location using a file:// url, or via FTP using ftp://localhost/path/to/directory.

Network shared pacman cache

If you happen to run several Arch boxes on your LAN, you can share packages so that you can greatly decrease your download times. Keep in mind you should not share between different architectures (i.e. i686 and x86_64) or you will run into problems.

Read-only cache

If you are looking for a quick and dirty solution, you can simply run a standalone webserver which other computers can use as a first mirror: darkhttpd /var/cache/pacman/pkg. Just add this server at the top of your mirror list. Be aware that you might get a lot of 404 errors, due to cache misses, depending on what you do, but pacman will try the next (real) mirrors when that happens.

Read-write cache

In order to share packages between multiple computers, simply share /var/cache/pacman/ using any network-based mount protocol. This section shows how to use shfs or sshfs to share a package cache plus the related library-directories between multiple computers on the same local network. Keep in mind that a network shared cache can be slow depending on the file-system choice, among other factors.

By default, smbfs does not serve filenames that contain colons, which results in the client downloading the offending package afresh. To prevent this, use the mapchars mount option on the client.

Then, to share the actual packages, mount /var/cache/pacman/pkg from the server to /var/cache/pacman/pkg on every client machine.

Note: Do not make /var/cache/pacman/pkg or any of its ancestors (e.g., /var) a symlink. Pacman expects these to be directories. When pacman re-installs or upgrades itself, it will remove the symlinks and create empty directories instead. However during the transaction pacman relies on some files residing there, hence breaking the update process. Refer to FS#50298 for further details.

two-way with rsync

Another approach in a local environment is rsync. Choose a server for caching and enable the Rsync#rsync daemon. On clients synchronize two-way with this share via rsync protocol. Filenames that contain colons are no problem for the rsync protocol.

Dynamic reverse proxy cache using nginx

nginx can be used to proxy requests to official upstream mirrors and cache the results to local disk. All subsequent requests for that file will be served directly from the local cache, minimizing the amount of internet traffic needed to update a large number of servers with minimal effort.

Warning: This method has a limitation. You must use mirrors that use the same relative path to package files and you must configure your cache to use that same path. In this example, we are using mirrors that use the relative path /archlinux/$repo/os/$arch and our cache's Server setting in mirrorlist is configured similarly.

In this example, we will run the cache server on http://cache.domain.local:8080/ and storing the packages in /srv/http/pacman-cache/.

Create the directory for the cache and adjust the permissions so nginx can write files to it:

Next, configure nginx as the dynamic cache (read the comments for an explanation of the commands).

Finally, update your other Arch Linux servers to use this new cache by adding the following line to the mirrorlist file:

/etc/pacman.d/mirrorlist

Server = http://cache.domain.local:8080/archlinux/$repo/os/$arch
...

Note: You will need to create a method to clear old packages, as this directory will continue to grow over time. paccache (which is included with pacman) can be used to automate this using retention criteria of your choosing. For example, find /srv/http/pacman-cache/ -type d -exec paccache -v -r -k 2 -c {} \; will keep the last 2 versions of packages in your cache directory.

Synchronize pacman package cache using synchronization programs

Preventing unwanted cache purges

By default, pacman -Sc removes package tarballs from the cache that correspond to packages that are not installed on the machine the command was issued on. Because pacman cannot predict what packages are installed on all machines that share the cache, it will end up deleting files that should not be.

To clean up the cache so that only outdated tarballs are deleted, add this entry in the [options] section of /etc/pacman.conf:

CleanMethod = KeepCurrent

Recreate a package from the file system

To recreate a package from the file system, use bacman (included with pacman). Files from the system are taken as they are, hence any modifications will be present in the assembled package. Distributing the recreated package is therefore discouraged; see ABS and Arch Rollback Machine for alternatives.

Tip: bacman honours the PACKAGER, PKGDEST and PKGEXT options from makepkg.conf. Custom options for the compression tools can be configured by exporting the relevant environment variable, for example XZ_OPT="-T 0" will enable parallel compression for xz.

An alternative tool would be fakepkgAUR. It supports parallelization and can handle multiple input packages in one command, which bacman both does not support.

List of installed packages

Keeping a list of explicitly installed packages can be useful to speed up installation on a new system:

$ pacman -Qqe > pkglist.txt

Note: If you used -Qqet, when reinstalling the list all the non-top-level packages would be set as dependencies.

To install packages from the list backup, run:

# pacman -S - < pkglist.txt

Tip: Use comm -13 <(pacman -Qqdt | sort) <(pacman -Qqdtt | sort) > optdeplist.txt to also create a list of the installed optional dependencies which can be reinstalled with --asdeps.

In case the list includes foreign packages, such as AUR packages, remove them first:

# pacman -S $(comm -12 <(pacman -Slq | sort) <(sort pkglist.txt))

To remove all the packages on your system that are not mentioned in the list:

# pacman -Rsu $(comm -23 <(pacman -Qq | sort) <(sort pkglist.txt))

Listing all changed files from packages

If you are suspecting file corruption (e.g. by software/hardware failure), but are unsure if files were got corrupted, you might want to compare with the hash sums in the packages. This can be done with pacutils:

Restore pacman's local database

Recovering a USB key from existing install

If you have Arch installed on a USB key and manage to mess it up (e.g. removing it while it is still being written to), then it is possible to re-install all the packages and hopefully get it back up and working again (assuming USB key is mounted in /newarch)

Find applications that use libraries from older packages

Even if you installed a package the existing long-running programs (like daemons and servers) still keep using code from old package libraries. And it is a bad idea to let these programs running if the old library contains a security bug.

Here is a way how to find all the programs that use old packages code:

# lsof +c 0 | grep -w DEL | awk '1 { print $1 ": " $NF }' | sort -u

It will print running program name and old library that was removed or replaced with newer content.

Performance

Database access speeds

Pacman stores all package information in a collection of small files, one for each package. Improving database access speeds reduces the time taken in database-related tasks, e.g. searching packages and resolving package dependencies. The safest and easiest method is to run as root:

# pacman-optimize

This will attempt to put all the small files together in one (physical) location on the hard disk so that the hard disk head does not have to move so much when accessing all the data. This method is safe, but is not foolproof: it depends on your filesystem, disk usage and empty space fragmentation. Another, more aggressive, option would be to first remove uninstalled packages from cache and to remove unused repositories before database optimization:

# pacman -Sc && pacman-optimize

Download speeds

Note: If your download speeds have been reduced to a crawl, ensure you are using one of the many mirrors and not ftp.archlinux.org, which is throttled since March 2007.

When downloading packages pacman uses the mirrors in the order they are in /etc/pacman.d/mirrorlist. The mirror which is at the top of the list by default however may not be the fastest for you. To select a faster mirror, see Mirrors.

Pacman's speed in downloading packages can also be improved by using a different application to download packages, instead of Pacman's built-in file downloader.

In all cases, make sure you have the latest Pacman before doing any modifications.

# pacman -Syu

Powerpill

Powerpill is a Pacman wrapper that uses parallel and segmented downloading to try to speed up downloads for Pacman.

wget

This is also very handy if you need more powerful proxy settings than pacman's built-in capabilities.

To use wget, first install the wget package then modify /etc/pacman.conf by uncommenting the following line in the [options] section:

Instead of uncommenting the wget parameters in /etc/pacman.conf, you can also modify the wget configuration file directly (the system-wide file is /etc/wgetrc, per user files are $HOME/.wgetrc.

aria2

aria2 is a lightweight download utility with support for resumable and segmented HTTP/HTTPS and FTP downloads. aria2 allows for multiple and simultaneous HTTP/HTTPS and FTP connections to an Arch mirror, which should result in an increase in download speeds for both file and package retrieval.

Note: Using aria2c in Pacman's XferCommand will not result in parallel downloads of multiple packages. Pacman invokes the XferCommand with a single package at a time and waits for it to complete before invoking the next. To download multiple packages in parallel, see Powerpill.

Install aria2, then edit /etc/pacman.conf by adding the following line to the [options] section: