XBPS Explained: Void Linux's Package Manager

✅ Verified against the official Void Linux Handbook (docs.voidlinux.org) and void-packages on GitHub — Last updated: September 2026

XBPS (X Binary Package System) is Void Linux's own package manager — not a fork of pacman or a wrapper around dpkg, but a from-scratch implementation built alongside the distro itself. Juan Romero Pardines, a former NetBSD developer, created both Void and XBPS in 2008 as a testbed for the package manager itself — which is also why xbps-src's source-build design draws on NetBSD's pkgsrc and BSD ports collections rather than anything from the Linux side. If you're coming from Arch or Debian, most concepts map over, but several specifics — the double-update quirk, no journalctl, and how the community package repo actually works — are different enough to catch you off guard. If you haven't installed Void yet, start with the installation guide.

Core Commands

The one that trips people up: if xbps-install -Su updates the xbps tool itself as part of that run, you need to run the exact same command a second time to finish updating everything else. This is documented official behavior in the handbook, not a bug you're hitting by accident.

Repositories

Repository configuration lives in /etc/xbps.d/ (see man xbps.d for the full format). Official repos are enabled by default; community and third-party repos are added by dropping a config file into that directory pointing at the repo's URL. If a repo starts returning 404s on repodata, that directory is the first place to check — it usually means a config file is pointing at a stale mirror path.

xbps-src: Void's Equivalent of the AUR (Sort Of)

Void doesn't have a community repo of auto-buildable scripts like Arch's AUR. Instead, packages not in the binary repos are built from void-packages, the same monorepo used to build Void's own official packages:

git clone https://github.com/void-linux/void-packages.git
cd void-packages
./xbps-src binary-bootstrap   # first run only, sets up the build chroot
./xbps-src pkg <package-name>

The built package lands in hostdir/binpkgs — install it from there:

xbps-install --repository hostdir/binpkgs <package-name>

The xtools package provides xi, a shortcut wrapper for this same workflow. The real difference from the AUR: there's no automatic script execution from community submissions — you're building from the same reviewed monorepo Void's own maintainers use, inside a sandboxed chroot. xbps-src also refuses to run as root by design.

When do you actually need this? Only when a package genuinely isn't in the binary repos yet — a brand-new release, a template someone submitted as a PR that hasn't merged, or software niche enough that nobody's packaged it for Void. For anything already in xbps-query -Rs, reach for xbps-install instead — xbps-src is a build tool for filling real gaps, not a general-purpose alternative to the binary repos you'd reach for by default.

Services and Logs Without systemd

Void uses runit, not systemd — there's no systemctl and no journalctl.

# enable a service
sudo ln -s /etc/sv/<service> /var/service/

# check status / control it
sv status <service>
sudo sv restart <service>

# disable
sudo rm /var/service/<service>

Void ships no syslog daemon by default. Logging goes through socklog (package socklog-void, services socklog-unix and nanoklogd), writing to /var/log/socklog/. View logs with:

svlogtail <service>

Access is restricted to root and the socklog group by default — add your user to that group if you need regular log access without sudo.

glibc vs musl — What It Actually Affects

Package availability is the practical impact, not something abstract. On musl, most proprietary software — the NVIDIA driver being the most common real-world blocker — doesn't work correctly, and there's no multilib/32-bit sub-repo or i686 musl binaries at all. On glibc, essentially everything works the way it does on other mainstream distros. If you picked musl during install and hit a wall with a specific piece of proprietary software, the handbook's documented workaround is running that one program from a glibc chroot rather than reinstalling the whole system.

A Third Option: Flatpak

Void officially packages Flatpak (confirmed in the current repo — xbps-query -Rs flatpak lists flatpak, flatpak-builder, and a flatpak-32bit multilib build). Install it the normal way:

xbps-install -S flatpak

This gives you a third path alongside XBPS and xbps-src: for apps distributed as Flatpaks on Flathub, that's often less friction than either waiting for a binary repo package or building from source yourself. It doesn't replace XBPS for system packages — it's an extra option for desktop apps specifically, same role it plays on any other distro.

Troubleshooting

Is xbps-src the same thing as the AUR?

No. The AUR runs community-submitted build scripts automatically. xbps-src builds from the same reviewed monorepo Void's own official packages come from, inside a sandboxed chroot you control — there's no equivalent of an unreviewed community script running arbitrary build steps.

Why do I have to run xbps-install -Su twice?

If the first run updated xbps itself, the update process needs to restart with the new version to finish updating the rest of the system. Documented behavior, not an error.

How do I check a service's logs without journalctl?

Use svlogtail <service>, reading from socklog's output in /var/log/socklog/. There's no centralized systemd-journal equivalent — each service's logs live under its own socklog directory.

Can I add a third-party repository?

Yes — drop a repository config file into /etc/xbps.d/ pointing at the third-party repo's URL, following the same format as the official repo configs already there.

Should I choose glibc or musl for a new install?

glibc, unless you have a specific reason to want musl's stricter, smaller base and don't need proprietary software like NVIDIA's driver.