Technology

I’ve been using Void Linux on several of my servers and my work laptop. I’ve found it to be a stable Linux distribution, with many of the tools I commonly use in its package repository. It is not derived off of another distribution, and is built around its own xbps package manager. Some of the commands for xbps are a bit difficult to remember, and it doesn’t have the best command line interface. Void also uses runit for service management, which also has some non-traditional ways of handling services. In this article, I’ll go over some valuable tools, such as vpm and vsv, which greatly improve the Void Linux command line experience. I’ll also go over voidup, a tool I built for creating custom package repositories on Void Linux.

Better Package Management

The package manager for Void Linux is called xbps. Individual operations all have their own commands, such as xbps-install and xbps-query. Having several individual commands is cumbersome, and I’ve found it difficult to remember all the switches I need for certain operations. The command help sections aren’t the best, and I found myself constantly looking through the man pages or searching the web to remind myself how to do common operations. The solution to this is vpm. vpm is just a wrapper for all the xbps-* commands, but with a better help system and commands that feel much more intuitive.

# vpm

 __ ___ __ _ __
 \ V / '_ \ '  \   vpm - void package management utility for XBPS
  \_/| .__/_|_|_|  GitHub: https://github.com/netzverweigerer/vpm
     |/
     ´
[vpm]  vpm - Version: UNKNOWN
[vpm]  Copyright (c) 2016 Armin Jenewein <a@m2m.pm> (GPLv3+)
[vpm]  XBPS version: XBPS: 0.59.1 API: 20200221

USAGE:
vpm [OPTIONS] [SUBCOMMANDS] [<ARGS>]

OPTIONS:
--color=<yes|no|auto>        - Enable/Disable colorized output (default: auto)
--help                       - (same as: help)
--help-pager                 - (same as: helppager)
--show-translations          - Show XBPS command translations for vpm sub-commands
--verbose                    - Verbose mode (shows XBPS command translations during execution)

SUBCOMMANDS:
sync                         - Synchronize remote repository data
update (up)                  - Update the system
listrepos (lr)               - List configured repositories
repolist (rl)                - Alias for listrepos
addrepo (ar) <ARGS>          - Add an additional repository
info <pkg>                   - Show information about <package>
...
...

The vpm wrapper is in the official Void Linux package tree, and can be installed by running xbps-install -Sy vpm. I consider vpm an essential tool, and it can make life easier for any Void Linux desktop user or server administrator.

Better Service Control

Most Linux distributions have migrated to using systemd for service and process management. Void Linux was built from the ground up to use runit, a very simple init system. The service launch configurations are all kept in /etc/sv and each service uses a run file with the commands needed to launch the daemon. These run files are incredibly simple compared to OpenRC scripts or systemd. A great tool for viewing service status on Void Linux is vsv.

vsv can be used to enable, disable and restart services. It still requires the creation of a symbolic link from /etc/sv to /var/services for a particular service to show up in the list.

Creating Custom Repositories

The current Void packaging and custom repository experience leave a lot to be desired. In order to make custom packages, you need to checkout the current void-packages repository, add in your custom templates, and use a series of xbps-src commands to build a binary package. xbps does support additional 3rd party repositories, but the current workflow seems to aim for contributors to submit patches to the official repository. If those contributions don’t get accepted, there’s no easy way to maintain your own repository. That’s why I created voidup, a command line tool that manages the base package tree, as well as additional overlays with custom package templates. It uses overlayfs to combine the base tree with additional git repositories or local directories in order to cleanly build packages. It supports building for multiple architecture targets (e.g. aarch64, x86_64-musl, etc.) and handles package indexing and signing.

The official Void Linux package repository also contains several non-free/proprietary package templates. Previously I had used the following shell script, and ran it occasionally to ensure I was on the latest versions of some of the software I need for work:

#!/usr/bin/env fish

set packages "zoom slack-desktop 1password sublime-text4 google-chrome"

cd $HOME/src/void-packages
git pull

for i in (string split " " $packages)
  echo Building: $i
  ./xbps-src pkg "$i"
end

sudo xbps-install --repository=hostdir/binpkgs/nonfree (string split " " $packages)

With voidup, I can build updates for these packages on a regular basis and publish them internally to a non-public web server. That way, I can keep multiple machines up to date, while only having to retrieve and build the packages once.

As of writing this, voidup is still in an alpha state. The project README has all the current details for installing and configuring the project. It’s currently used to build the BattlePenguin Void Linux Repository or BPVL, a repository of packages for both my personal projects, and other projects I’ve chosen to maintain.

Void Linux on Vagrant using Packer

The void-mklive repository has tools for building various cloud images from Void Linux. However, it’s not very well documented. I had to dig through the issues to discover how to create a Vagrant image using Packer¹.

git clone https://github.com/void-linux/void-mklive
cd void-mklive/packer
packer build -only="vagrant-virtualbox-x86_64.virtualbox-iso.x86_64" hcl2

The resulting vagrant-virtualbox-x86_64.virtualbox-iso.x86_64 image file can be placed in a directory with a Vagrant configuration like the following:

Vagrant.configure("2") do |config|

  config.vm.box = "./vagrant-virtualbox-x86_64.box"

  config.vm.synced_folder "/home/myuser/workspace/voidup", "/voidup"
  config.vm.synced_folder "/home/myuser/workspace/BPVL", "/BPVL"

   config.vm.provider "virtualbox" do |vb|
     vb.memory = 16384
     vb.cpus = 12
   end

   config.vm.provision "shell", inline: <<-SHELL
     xbps-install -Syu fish-shell vpm vsv bat xtools vim
   SHELL
end

In the above example, I map the voidup and BPVL project directories directly into the Vagrant VM, and install some helpful tools in the provision script. This machine can be started using vagrant up and accessed via vagrant ssh. These Vagrant boxes are great for developing integration tests with custom package repositories.

The Problems with Void Linux

As I’ve worked on voidup to build custom packages, I’ve run into a lot of interesting issues and caveats. Most are simply technical issues or limitations. Some issues arise from the general philosophy of the Void package maintainers. Finally, because everything today is horrible, some of the issues seem to be political in nature. I’ll address the issues I’ve encountered, as well as possible workarounds if they exist.

No Stable/Unstable Package Tree

Void Linux has a stable rolling release system. If this feels like a contradiction, it is. Gentoo has rolling releases, but packages can be marked as stable or unstable. I keep my Gentoo system stable, occasionally adding unstable packages (using the ~amd64 package keyword) into my system. OpenSUSE has two different versions: Leap and Tumbleweed. Leap has a standard version numbering system with updates, while Tumbleweed has continual bleeding edge updates. Void Linux could support both stable and testing repositories using xbps, but it only has a stable repository. From what I can gather, testing is done by individual maintainers before pushing updates to the package tree, allowing things like IPv6 in dhcpcd to be broken for weeks².

Having an unstable package tree allows users to contribute to testing potential updates. It lets developers keep unstable releases on non-critical machines and provide feedback for issues they encounter. The continuous build and release process in Void Linux, with no beta release channel, is really baffling to me. It feels like a roadblock from Void being used in larger production environments.

Automatic Package Removal

I still use the ancient gmpc client for Music Player Daemon (MPD). This tool is no longer maintained and uses ancient versions of several libraries. It’s been removed from Gentoo Portage and from Void Packages. However, when it was removed from Gentoo portage, the ebuild file was removed, but the application itself was not purged from my system. Void Linux uses a removed-packages package to force the removal of applications. I was able to use downgrading and package holding³ to reinstall gmpc and ensure it wouldn’t get removed in the future.

Other users have had similar issues, such as VeraCrypt unexpectedly being uninstalled during package updates⁴. Even as I was working on this article, someone in the Void Linux chatroom on Libera Chat was commenting on the neofetch package being removed. A maintainer commented, “These worthless stat printers need to go the way of the dinosaurs.”

<god_from_machine> anyone else somehow get neofetch somehow uninstalled on its own? I see it still exists in xbps, just not installed, but i run it like once a day. strange
<TheAnachron> isnt it dropped?
<TheAnachron> afaik it has been removed from the repos
<luca> Yeah, and it's a part of removed-packages package as well
<luca> So you probably want to move to fastfetch or whatever
<kynikossdragonn> I went through the void-packages commit history and I don't see a specific commit explicitly saying neofetch is removed.
<kynikossdragonn> unless I'm blind
<Johnnynator> https://github.com/void-linux/void-packages/commit/6e1941d07e68e3cd30c85effb74612efbcb4ee50
<treflip> why?
<treflip> oh, I see, everyone says it's discontinued
<Johnnynator> Multiple reasons: a) upstream discontinued it and b) it is just a shell script just download https://raw.githubusercontent.com/dylanaraps/neofetch/refs/heads/master/neofetch and run it. No compiling, patching, or other pain needed
<ahesford> c) these worthless stats printers need to go the way of the dinosaur
<luca> legendary message from the developer https://github.com/dylanaraps/dylanaraps/blob/master/README.md
<Johnnynator> (Okay, you might have to download the full src to get the pictograms, but 🤷)
<treflip> XD
<Johnnynator> ahesford: not all are useless, inxi can be usefull imo

I’m not a big fan of automatic package removal. In all the cases mentioned above, the underlying tools still worked! Only the case of VeraCrypt ran into licensing issues⁵. I can understand the reasoning behind implementing package removal this way, if Void Linux was intended to be a mainstream distribution. However, as I’ve already mentioned, Void has no unstable version. It’s geared towards developers and power users, and removing packages just feels like a rug pull. Sure, you see the packages being removed when you do an update, but it’s easy to miss these. I schedule my updates automatically, so I never see these removals.

I decided to uninstall removed-packages. The base-system package is dependent on it, so I set it to be ignored using xbps configuration. This could cause issues in the future, but if you want to prevent package removal, the following might work:

echo "ignorepkg=removed-packages" > /etc/xbps.d/stop-removal.conf
xbps-remove removed-packages

Name             Action    Version           New version            Download size
removed-packages remove    0.1.20241213_1    -                      -

Space available on disk:       191GB

Do you want to continue? [Y/n]

Just because a package is unmaintained doesn’t mean it should be discarded. Services could contain security bugs and require more scrutiny, but some very old tools are just feature complete and don’t need any new updates. The removal of neofetch and the reasons give in the chat shadow the philosophy and mentality of the maintainers, which will show up again in other issues I encountered.

Python

When working on voidup, I discovered some of my previously built packages no longer worked. They were built for Python 3.12 and Void had updated to Python 3.13. Void Linux appears to have no means of handling multiple versions of interpreted languages like Ruby and Python. Gentoo uses package slots and its eselect tool to maintain and switch between different versions of interpreted languages. Debian and Ubuntu include the version in the package name, with python3.11-full on Debian Bookworm and python3.12-full on Ubuntu Nobel. Updating to a new release of Python on such systems often occurs with the full distribution update. Void Linux appears to do full Python updates every year in October⁶, using an incredibly involved process⁷ that can result in a lot of breakage⁸.

Void Linux does have a command called xbps-alternatives, which could have been used to facilitate multiple versions of system packages, similar to Gentoo’s slot and eselect system. Not having discrete release numbers, or a means to handle multiple Python versions, combined with arbitrary updates of all Python packages once a year, makes it very difficult to maintain Python packages in third party repositories for Void Linux. I’m now greatly reconsidering my decision to write voidup in Python and am not sure what approach I should take to handle these types of updates. Void Linux is probably not the best distribution to use if you’re a Python developer, especially around October.

Hyprland

The earliest request to package Hyprland for VoidLinux was in 2022, but it was closed due to the way Hyprland embedded their own version of wlroots⁹. After Hyprland migrated off of wlroots, another request was opened for a Hyprland package. The only responses were “Nope” and “We have no interest in maintaining a hyprland package¹⁰.” The latest request for a Hyprland package suggests the reason for not allowing it is political¹¹, revolving around Hyprland’s ban from the FreeDesktop project¹². There is a hyprland-void project with all the necessary templates to build Hyprland packages for Void Linux. However, the templates cannot be updated for the latest version of Hyprland due to Void Linux not having a package for gcc14¹³.

I’ve had my own adventures in Hyprland, and have also covered the absolutely insane political controversy over Hyprland. It greatly saddens me that the Void Linux maintainers seem to be ideologically driven to not include packages for one of the fastest growing tiling composers for Wayland.

Conclusions

I started using Void Linux on some of my systems in place of Alpine. I initially liked the simplicity of its design and process management models. Today I use it on my router, a cloud VM, my dedicated servers, LXC containers on Proxmox, my work laptop and many of the servers in my home lab. Although I like using Void Linux on servers, I still prefer my decade old Gentoo install for my personal desktop Linux system.

I wrote this post to document some of the tools I’ve been using to make managing Void Linux easier. This past year was the first time I attempted to build packages. My first contribution was for supervisor, the Python based process control system. After following the guidance in the code review, my patch request went unanswered for nearly two months. I closed the request with a link to where I had published the package on the BPVL, and that comment was minimized so that no one can see where to get this package without logging into Github¹⁴.

Where other distributions welcome contributions, the maintainers of Void Linux seem very hostile to allowing in new packages. Forks of Firefox and Chromium (including Librewolf and Brave) are generally not allowed¹⁵. Custom repositories are discouraged over using other package management systems like Flatpak.

I wrote voidup because there didn’t seem to be a lot of good tools for making custom repositories. Most people just seemed to use a kludge of shell scripts and GitHub actions. As I start diving deeper into the core of Void Linux, I really hope others can make use of my contributions to build more package repositories and a richer ecosystem.

It seems like Void Linux is built around the idea that all packages should be part of the core void-packages system. Everything about the packaging process makes it much more difficult to have independent distributed repositories. Contrast this to Gentoo, where it encourages and depends heavily on a system of overlays for experimenting with and testing out packages. Even Gentoo’s core portage tree has a truly maddening amount of maintained packages, providing a large amount of the tools most users need and use.

Working on voidup and building Void packages has been an eye-opening experience. I’m pretty heavily committed to Void Linux on multiple systems and clusters. I want to continue to contribute to Void Linux and make it a good experience for those who want to use it for server applications. However, many of the dragons and pitfalls I’ve found have made me consider other options as I build out more projects in the future.