Void is a general purpose operating system, based on the monolithic Linux kernel. Its package system allows you to quickly install, update and remove software; software is provided in binary packages or can be built directly from sources with the help of the XBPS source packages collection.
It is available for a variety of platforms. Software packages can be built natively or cross compiled through the XBPS source packages collection.
Visit the Void build server console for package build status updates.
Void Linux is an independent distribution, developed entirely by volunteers.
Unlike trillions of other existing distros, Void is not a modification of an existing distribution. Void's package manager and build system have been written from scratch.
Void focuses on stability, rather than on being bleeding-edge. Install once, update routinely and safely.
Thanks to our continuous build system, new software is built into binary packages as soon as the changes are pushed to the void-packages repository.
Void Linux supports both the musl and GNU libc implementations, patching incompatible software when necessary and working with upstream developers to improve the correctness and portability of their projects.
xbps is the native system package manager, written from scratch with a 2-clause BSD license.
XBPS allows you to quickly install/update/remove software in your system and features detection of incompatible shared libraries and dependencies while updating or removing packages (among others). Refer to the Handbook for an overview.
xbps-src is the xbps package builder, written from scratch with a 2-clause BSD license.
This builds the software in containers through the use of Linux namespaces, providing isolation of processes and bind mounts (among others). No root required!
Additionally, xbps-src can build natively or cross compile for the target machine, and supports multiple C libraries (glibc and musl currently).
Void is a complex system, and over time we make changes to reduce this
complexity, or shift it to easier to manage components. Recently
through the fantastic work of one of our maintainers
our repository sync system has been dramatically improved.
Previously our system was based on a series of host managed rsyncs running on either snooze or cron based timers. These syncs would push files to a central location to be signed and then distributed. This central location is sometimes referred to as the “shadow repo” since its not directly available to end users to synchronize from, and we don’t usually allow anyone outside Void to have access to it.
As you might have noticed from the Fastly Overview the packages take a long path from builders to repos. What is not obvious from the graph shown is that the shadow repo previously lived on the musl builder, meaning that packages would get built there, copied to the glibc builder, then copied back to the musl builder and finally copied to a mirror. So many copies! To streamline this process, the shadow mirror is now just the glibc server, since that’s where the packages have to wind up for architectural reasons anyway. This means we were able to cut out 2 rsyncs and reclaim a large amount of space on the musl builder, making the entire process less fragile and more streamlined.
But just removing rsyncs isn’t all that was done. To improve the time it takes for packages to make it to users, we’ve also switched the builders from using a time based sync to using lsyncd to take more active management of the synchronization process. In addition to moving to a more sustainable sync process, the entire process was moved up into our Nomad managed environment. Nomad allows us to more easily update services, monitor them for long term trends, and to make it clearer where services are deployed.
In addition to fork-lifting the sync processes, we also forklifted void-updates, xlocate, xq-api (package search), and the generation of the docs-site into Nomad. These changes represent some of the very last services that were not part of our modernized container orchestrated infrastructure.
Visually, this is what the difference looks like. Here’s before:
And here’s what the sync looks like now, note that there aren’t any cycles for syncs now:
If you run a downstream mirror we need your help! If your mirror
has existed for long enough, its possible that you were still
synchronizing from alpha.de.repo.voidlinux.org, which has been a dead
servername for several years now. Since moving around sync traffic is
key to our ability to keep the lights on, we’ve provisioned a new
dedicated DNS record for mirrors to talk to. The new
repo-sync.voidlinux.org is the preferred origin point for all sync
traffic and using it means that we can transparently move the sync
origin during maintenance rather than causing an rsync hang on your
sync job. Please check where you’re mirroring from and update
Happy Pythonmas! It’s October, which means it’s Python 3 update season. This year, along with the usual large set of updates for Python packages, a safety feature for pip, the Python package manager, has been activated. To ensure that Python packages installed via XBPS and those installed via pip don’t interfere with one another, the system-wide Python environment has been marked as “externally managed”.
If you try to use
pip3 --user outside of a Python virtual environment,
you may see this error that provides guidance on how to deploy a virtual
environment suitable for use with pip:
This system-wide Python installation is managed by the Void Linux package manager, XBPS. Installation of Python packages from other sources is not normally allowed. To install a Python package not offered by Void Linux, consider using a virtual environment, e.g.: python3 -m venv /path/to/venv /path/to/venv/pip install <package> Appending the flag --system-site-packages to the first command will give the virtual environment access to any Python package installed via XBPS. Invoking python, pip, and executables installed by pip in /path/to/venv/bin should automatically use the virtual environment. Alternatively, source its activation script to add the environment to the command search path for a shell: . /path/to/venv/activate After activation, running deactivate will remove the environment from the search path without destroying it. The XBPS package python3-pipx provides pipx, a convenient tool to automatically manage virtual environments for individual Python applications.
You can read more about this change on Python’s website in PEP 668.
To simplify the use of Void-based containers, all Void container images
20231003R1 or later will explicitly ignore the “externally managed”
marker. Containers based on these images will still be able to use pip to
install Python packages in the container-wide environment.
If you really want to be able to install packages with pip in the system- or user-wide Python environment, there are several options, but beware: this can cause hard-to-debug issues with Python applications, or issues when updating with XBPS.
--break-system-packagesflag. This only applies to the current invocation.
pip3 config set install.break-system-packages True. This will apply to all future invocations.
noextract=/usr/lib/python*/EXTERNALLY-MANAGEDrule to your XBPS configuration and re-install the
python3package. This will apply to all future invocations.