XBPS package manager

Instead of a single program, the XBPS package manager consists of a collection of 15 programs at the time of writing. For the usual installation and maintenance of a Void Linux system, these are the four most relevant ones:

• xbps-install to install/reinstall or upgrade packages, to sync the local index of packages with the configured repo/mirror and to perform system updates.
• xbps-pkgdb to modify the package database. Operations include setting a package ‘on-hold’ to prevent the package from being updated during a system update.
• xbps-query to list the configured repos and information about installed packages
• xbps-remove to remove packages.

The remaining 14 programs are intended for package maintainers.

Additionally, the xtools package provides tools that are usually interesting for package maintainers only, except of the following two tools:

• xcheckrestart: finds processes running a different version of a program than the version installed. This is useful to find services that have been updated during a system update. XBPS does not automatically restart services after an update.
• xlocate: works like locate, but for XBPS packages. xlocate <file> lists the package(s) that provide file <file>.

XBPS keeps a local index of all packages in the configured repo/mirror.

configuration

Installing Void from a Live-Installer will automatically install the files necessary to configure XBPS:

• 00-repository-main.conf: configures the repo/mirror for XBPS
• void-virtualpkgs.conf: defines virtual packages. Virtual packages are resolved to real packages.
• xbps-arch.conf: defines the architecture for which XBPS installs packages. This file shouldn’t be edited.
• xbps.conf: contains the default values (commented out) for the XBPS configuration

When installing Void via chroot with the XBPS method (see Installation via chroot), the files in /usr/share/xbps.d from the installation medium can be copied to /etc/xbps.d.

For both methods, XBPS runs out of the box. However, it is recommended to configure the XBPS mirror to decrease the load on the default mirror and to improve the speed of XBPS.

mirror setup

There are tier 1 mirrors and tier 2 mirrors. tier 1 mirrors usually get synced within an hour or so. Tier 2 mirrors sync from a nearby Tier 1 mirror when possible.

The publicy available grafana dashboard defines out of sync mirrors as “Mirrors, that haven’t synced for at least 5 days”. The topicality of tier 2 mirrors varies a lot, with some tier 2 mirrors being out of sync for weeks or even years.

Before configuring the mirror for XBPS, the topicality of the mirrors should be checked with the mirror list available at Void Linux Mirrors or the grafana dashboard mentioned above.

syncing XBPS with the mirror

To sync XBPS with the mirror and update the index, use xbps-install -S.

system update

xbps-install -u performs a system update. Before the update operation, XBPS should be synced with the configured mirror with xbps-install -S. Both operations can be combined with xbps-install -Su, except when updating XBPS. In this case, xbps-install -Su must be run twice, the first time to update XBPS itself, the second time to update the rest of the system.

xbps-install -Syu updates the system without asking questions, assuming ‘yes’ as the answer for any question.

updated services

XBPS does not restart services when they are updated. This task is left to the sysadmin. For finding processes running a different version of a program than the version installed, the xtools package provides xcheckrestart

xcheckrestart lists the process of any such service, together with its PID, path to executable, status of the path that it was launched from (might be deleted because of an update), and the process name.

preventing kernel panic after an update

A possible cause for a kernel panic after an update is that there is no space left in /boot because of too much kernel versions installed in there.

A possible strategy to counter this is to pin the package linux (see pinned packages below) and periodically upgrade the kernel manually with xbps-install -fu linux after checking the space left in /boot.

installing packages

xbps-install <package> installs the package .

installing specific package versions

With xbps-install <package>[ < | <= | == | => | > ]<version>, specific versions or version ranges of a program can be installed. I.e. with xbps-install banana==2.0, package banana, version 2.0, is installed, while with xbps-install banana>=2.0, banana, version 2.0 or later is installed.

checking operations with ‘–dry-run’

xbps-install and xbps-remove have the parameter --dry-run (or, short: -n). With this parameter xbps-install and xbps-remove do not execute the specified operations but only report them, i.e. xbps-install -n mooh reports which packages will be installed as dependencies of package mooh, in addition to package mooh being installed. xbps-remove -nR mooh lists mooh and dependencies that are no longer needed when package mooh is uninstalled and that will be uninstalled together with package ‘mooh’.

getting information about packages

• xbps-query -l lists all installed packages.
• xbps-query -H lists all pinned packages (see pinned packages below).
• xbps-query -f <package> lists all files that package <package> provides.
• xbps-query -m <package> lists all packages that have been installed manually, that is, all packages that have not been installed as a dependency but have been installed explicitly, i.e. with xbps-install <package>.
• xbps-query -x <package> lists all run-time dependencies of package <package>.
• xbps-query -X <package> lists all packages, for which package is a run-time dependency (lists reverse dependencies of package ).
• xbps-query -l | awk '{ print $2 }' | xargs -n1 xbps-uhelper getpkgname lists all installed packages without their version.
• xbps-uhelper version <package> prints the version of package <package>.

orphaned packages

xbps-query -o list orphaned packages.

I.e., at the time of writing xbps-query -o lists on my system, among other stuff, several fonts and programs like ffmpeg, xdpyinfo, which I occasionally use. xbps-remove -o --dry-run reports that it will remove all these packages when running xbps-remove -o.

modifying the package db

modifying the package mode

Package have either the package mode auto – the package has been installed as a dependency, or the package mode manual – the package has been installed explicitly by the user. The package mode can be set with xbps-pkgdb -m auto <package>, respectively xbps-pkgdb -m manual <package>.

Packages in mode manual are not detected as orphaned packages.

pinned packages

Packages can be pinned to their current version (set on hold in XBPS speak) with xbps-pkgdb -m hold and can be unpinned with xbps-pkgdb -m unhold. Pinned packages do not get updated during a system update with xbps-install -u.

However, xbps-install -fu <package> updates a package regardless whether it is pinned or not.

cleaning up the package cache

xbps-remove -O cleans the cache directory and removes outdated packages and/or packages with wrong hash.

references

man pages of xbps-<whatever> programs

man pages of xtools

Void Linux documentation: XBPS Package Manager

Void Linux documentation: Void Linux Mirrors

XBPS on github: void-linux/xbps