Creating distro build tooling for a small community

Key points

Chimera Linux's founder has published a long post, dated 7 October 2026, explaining why the project builds everything with its own tool, cbuild: the principles behind it, how it grew out of experience with Void Linux's xbps-src, why Chimera moved to apk, and how the build infrastructure works.

Design principles

• Chimera is a small project that serves its community, so maintenance cost has to stay low and the barrier to packaging is meant to be low: every user can be a packager.
• One tool does everything: the repository, the build environment, repository generation and signing, parts of the version-control handling and routine maintenance. There are no external helpers.
• Most packaging mistakes are hard errors. Builds are heavily sandboxed, the build environment is kept consistent, unit tests run by default, and formatting, dependencies and metadata (down to dependency ordering and the SPDX licence expression) are checked automatically.
• cbuild runs on any Linux system. It is a developer tool for work that gets shared upstream, with no guarantees for local-only use.
• The project's whole remote infrastructure can be reproduced locally in about an hour, and most of it in about five minutes.

A first package, as shown in the post

git clone https://github.com/my-user/cports
cd cports
./cbuild keygen
./cbuild bootstrap
./cbuild pkg user/my-cool-program
git checkout -b my-cool-program
./cbuild commit user/my-cool-program
git push origin my-cool-program

Updating a package and building in bulk

./cbuild bump-pkgver user/my-program 4.20.69
./cbuild prepare-upgrade user/my-program
./cbuild pkg user/my-program
./cbuild commit user/my-program
./cbuild update-check main/firefox
./cbuild bulk-pkg git:origin/master..HEAD
./cbuild bulk-pkg status:outdated

• Other maintenance commands prune the local repository, bump versions and revisions, inspect dependency graphs, update sha256 checksums and check whether the local repository can be unstaged against the remote one.

What the author found lacking in xbps-src

• The author maintained Void's ppc64le port downstream from about 2018 to 2023, became an upstream Void maintainer, started Chimera in 2021 and left the Void team in 2023.
• The shell-based system was slow: parsing every template could take up to half an hour.
• It was permissive: network access during the whole build, a read-write build container with nothing guaranteeing its state afterwards, and few lints on the resulting packages.
• Useful tooling and extra lints live separately in xtools and are not mandatory.
• Templates often rely on in-place sed calls instead of patches, and patches are applied fuzzily.
• The builders do not run each package's test suite (only pull-request CI does), and every architecture other than x86_64 and i686 is cross-compiled.
• Staging covers only shared-library SONAME changes, and removing obsolete packages was done by hand.

How cbuild answers that

• It began as a ground-up rewrite of xbps-src in Python; templates are Python scripts too.
• Speed: several thousand templates are parsed and their metadata dumped in under a second.
• Strictness: no network from the configure step on, write access only to the build directory (and the destination directory during install), sandboxing with namespaces through Bubblewrap.
• Portability: the only dependencies are Python without external modules, Bubblewrap, Git and the package manager binary.
• Everything is signed as it is built; unsigned packages are not allowed.
• Chimera started on ppc64le only, and further targets were added later.

Why apk replaced xbps

• FreeBSD's pkg was the original idea, but was not ready for this use and its upstream advised choosing something else.
• apk has a real dependency solver, so fewer workarounds are needed from packagers.
• Shared libraries and commands are virtual packages (so:libfoo.so.1=1, cmd:foo) that can be searched and installed by name, with no central SONAME mapping file.
• apk has real triggers that run once at the end of a transaction; xbps-src emulates them with per-package scripts that run repeatedly, in the middle of it.

Build infrastructure

• The orchestrator is Buildbot, under one rule: what the packager runs is exactly what the remote build machine runs.
• A webhook reports that cports changed, without saying what. Each worker (one per architecture) pulls the tree, runs ./cbuild bootstrap-update, lists the work with ./cbuild bulk-print-ver status:unbuilt, builds each entry into a staging area and then tries to unstage.
• Unstaging fails if a provider was removed while something still depends on it, so reverse dependencies are always rebuilt before anything is published.
• The repository is then pruned and synced to the primary mirror: new packages first, then the indexes, then deletion of old packages.
• Listing and building can be done locally with one command:

./cbuild bulk-pkg status:unbuilt

• Builders: x86_64 (16-core EPYC root server at Netcup), aarch64 (80-core Ampere Altra), ppc64le (18-core/72-thread POWER9) and loongarch64 (Loongson 3A6000), all running Chimera; riscv64 is a 64-core Milk-V Pioneer provided by Zach van Rijn of Adélie Linux, running Fedora.
• The builders are not exposed to the Internet; the orchestrator and the primary repository each sit on their own machine, and each architecture has its own signing key.

Summary by DistroNews, based on the original post.