XBPS is a from-scratch package system whose API is the point

Written from scratch, and portable on purpose

The X Binary Package System, in short XBPS, is a binary package system designed and implemented from scratch. Its goal is to be fast, easy to use, bug-free, featureful and portable as much as possible.

The portability claim is specific. The XBPS code is totally compatible with POSIX/SUSv2/C99 standards, and it is released with a Simplified BSD license, 2 clause.

That is a deliberate bet against the way most package managers are written. The two clause licence is short enough to read in a minute, the C99 and POSIX constraint means the code compiles on old systems and on the musl based toolchains a distribution like Void uses, and writing it from scratch rather than deriving it from an existing system means there is no historical constraint about the format. The format is XBPS's own, and the tools that read it are the ones in this repository.

The project credits Juan Romero Pardines as the main author, with Enno Boland and Duncan Overbruck also named, and it is hosted under the void-linux organisation, which is how it came to be Void Linux's package system.

The feature list is long and it is where the design shows. Multiple local and remote repositories over HTTP, HTTPS and FTP, with RSA signed remote repositories, which the README marks as new in 0.27. Multiple compression formats for both repositories and package archives, gzip with zlib, bzip2, lz4, xz and zstd, with zstd as the default. SHA256 hashes for package metadata, files and binary packages.

The operational features are the ones that separate a package manager from a tarball downloader. Package states, in the style of dpkg, to mitigate broken package installs and updates. The ability to resume a partial package install or update. The ability to unpack only files that have been modified in an update, which is what makes a large package update cheap. Virtual packages. The ability to ignore completely any number of packages in dependency resolution. Checking for incompatible shared libraries in reverse dependencies. Updating reverse dependencies of any number of packages, or globally, in a single transaction. Replacing packages, holding packages so they are never updated, which is new in 0.16, preserving and updating configuration files, forcing reinstallation, downgrading any installed package, and running pre, post install, remove and update scriptlets.

There is also a package integrity check covering missing files, hash mismatches, missing or unresolved forward and reverse dependencies, and dangling or modified symlinks.

The library API is the product, the utilities are frontends

The README states there is a well documented API provided by the XBPS Library that is the basis for its frontends to handle binary packages and repositories. That sentence is the architecture.

The utilities are the frontends. The xbps package includes the following utilities among others, not a complete list: xbps-create to create binary packages, xbps-dgraph to generate dot(1) graphs, xbps-install to install and update packages, xbps-pkgdb to report and fix issues in pkgdb, xbps-query to query for package and repository information, xbps-reconfigure to configure installed packages, xbps-remove to remove packages, and xbps-rindex to handle local binary package repositories.

Each of those is a thin client over the library, and the library is where the package format, the repository protocol, the solver and the transaction logic live. A tool that wants to do something the shipped frontends do not is written against that API rather than by parsing command output or by reimplementing the format.

Two of the utilities are worth calling out for what they imply. xbps-dgraph generating dot(1) graphs means the dependency graph is a first class object in the data model rather than something reconstructed from output, and xbps-pkgdb reporting and fixing issues in pkgdb means the installed package database is treated as a thing that can be inconsistent and repaired, which follows from the package states feature.

The package expression syntax is the other user-facing surface the README starts to document. A package expression is a form to match a pattern, and XBPS 0.19 and later support three ways to specify them: by specifying a package name such as foo, by specifying the exact package name and version such as foo-1.0_1, and by specifying a package name and version separated by a version comparator, where the comparators include less than, greater than and less than or equal.

Three ways to say the same thing is unusual for a package manager and it is what lets a single argument mean different things depending on what you are doing with it, whether you are installing, querying, removing or holding.

Building it needs a hand written configure script

The build requirements are listed in full, and they are a good indicator of what the library links against.

You need a C99 compiler, clang, gcc, pcc or tcc, a POSIX compatible shell, GNU make, pkgconf, zlib, openssl or libressl, and libarchive 3.3.3 or newer with lz4 and zstd support. Optionally, graphviz and doxygen with the --enable-api-docs flag to build API documentation, and atf 0.15 or newer with --enable-tests to build the Kyua test suite.

The libarchive requirement is the substantive one. libarchive is what reads the compressed package archives, and the lz4 and zstd support is what makes the compression format list work. The version floor of 3.3.3 means a distribution with an older libarchive cannot build XBPS without a newer one.

The build itself uses a standard configure script, and the README notes explicitly that it is not generated by GNU autoconf. The example:

$ ./configure --prefix=/blah
$ make -jX
$ make install

By default PREFIX is set /usr/local and may be changed by setting --prefix in the configure script, and the DESTDIR variable is also supported at the install stage. There are some more options that can be tweaked, seen with ./configure --help.

The Makefile reflects the hand written approach. It includes an optional config.mk, sets SUBDIRS to include, lib, bin and data, and adds doc and tests conditionally on BUILD_API_DOCS and BUILD_TESTS. The all target refuses to run if config.mk is missing, with the message You didn't run ./configure ... exiting. The install target copies both the LICENSE and the LICENSE.3RDPARTY files into the shared licences directory, which is the two clause licence plus the separate terms for the third party code, and the repository has a 3RDPARTY directory at the top.

The check target removes any result.db files and runs ./run-tests, so the test harness is a script in the repository rather than a makefile convention.

The dumb build path that avoids polluting your system

There is a section of the README that is unusually considerate, and it is worth reading because it is the route most contributors will actually take.

Building and testing for dummies:

$ git clone https://github.com/void-linux/xbps
$ cd xbps
$ ./configure --enable-rpath --prefix=/usr --sysconfdir=/etc
$ make -j$(nproc)
$ make DESTDIR=~/xbps-git install clean
$ export PATH=~/xbps-git/usr/bin:$PATH
$ xbps-query -V

The reason is the --enable-rpath flag. Thanks to it you can install it anywhere and it will still use the libxbps shared library at $ORIGIN/../lib, which means that if xbps is installed to $HOME/xbps-git/usr, the executables will use $HOME/xbps-git/usr/lib to locate libxbps.

That is what makes the DESTDIR install safe. The library is resolved relative to the binary rather than through the system loader path, so an experimental build sitting in a home directory cannot pick up, or be picked up by, the system copy of libxbps. For a package manager, that isolation is not a nicety, because a mismatched library and frontend would be a corrupted package database.

The make install clean combination is worth noting too. It installs into the DESTDIR and then cleans, which removes the intermediate build objects from the staged directory.

For the full test suite, the README says to make sure kyua is installed and run:

$ ./configure --enable-tests
$ make
$ make check

And for people who just want a binary, static Linux builds compiled with the musl C library are published for aarch64, armv6l, armv7l, i686 and x86_64, available on all official void mirrors along with their sha256 checksums.

Where XBPS is the wrong choice

The first limit is the ecosystem. XBPS is a package system without a large independent package catalogue. Void Linux is its primary consumer, and a user who is not on Void has little reason to reach for it. A distribution whose official package manager is XBPS has a first class reason to exist, and a user on Ubuntu does not.

The second is the maturity of the surrounding tooling. The project ships a very capable core, and the surrounding ecosystem of frontends, graphical tools, security tooling and third party integrations is smaller and less predictable. A team that needs an auditable, scriptable package manager for a Void based appliance gets that. A team that wants a package manager with a large plugin surface does not.

The third is the version scheme. The releases are 0.60.5 from August 2025, 0.60.6 from November 2025 and 0.60.7 from February 2026, with the last push on 2026-05-01. So the numbering is 0.x with a 0.60 line, which in a stable system means the interface can still change, and the changelog is NEWS in the repository rather than a set of tags with release notes.

The fourth is the build requirements versus the portability claim. The code targets POSIX, SUSv2 and C99, but the build needs libarchive 3.3.3 or newer with lz4 and zstd, pkgconf and either openssl or libressl. That is a short and reasonable dependency list, but it is not zero, and on a platform where libarchive is old or absent, the system package manager is still needed to bootstrap.

The fifth is that the package format is XBPS's own. There is no cross-distribution interoperability, and a tool that wants to consume packages from several ecosystems has to handle the format itself. The library API makes that possible in principle, which is the point of the design, but it is still work.

Editorial conclusion

XBPS suits someone who wants a package manager that is small, portable and written in C with a stable library boundary, and it is the wrong tool if you want the largest package catalogue, since its ecosystem is Void's own. Before building it, note that libarchive 3.3.3 or newer with lz4 and zstd support is a hard requirement, and that the configure script is hand written rather than generated by autoconf, so the options are not the ones you expect. Verify first that the frontend you want to build can be built on the library API rather than by shelling out to the utilities, since that is the design the project is built around.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. void-linux/xbps on GitHub