Creating distro build tooling for a small community

本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

07.10.2026 A lot of people have been commenting on this over time so I figured I would put together a little post summarizing my thoughts on the matter and everything else. The post is going to be quite large. Every section can be read more or less separately, but they are all connected to each other.

2026年10月7日，随着时间的推移，很多人一直在评论这件事，所以我决定写一篇简短的文章，总结一下我对这件事以及其他所有事情的看法。这篇文章会很长。每一节都可以或多或少地独立阅读，但它们之间又是相互关联的。

Catering to the community Chimera is a small project. It exists primarily to serve its community and not any external entity. Making sure the maintenance cost is as low as possible is crucial. Chimera and its tooling are designed to automate away most of the boring stuff and make sure the packager’s job is pleasant and not bothersome. In a way, we aim to empower every user to be a packager. The barrier of entry is meant to be very low.

服务社区：Chimera 是一个小型项目。它的存在主要是为了服务其社区，而不是任何外部实体。确保维护成本尽可能低至关重要。Chimera 及其工具旨在自动化处理大部分枯燥的工作，并确保打包者的工作愉快且不繁琐。在某种程度上，我们的目标是让每一位用户都有能力成为打包者。我们希望将准入门槛降到最低。

Some things that implies (I will try really hard to make this reasonable to follow, unfortunately the years have left their mark and I might be taking some assumptions for granted, so please bear with me; this also applies in the later sections): Everyone uses the same tools. Inefficient UX patterns are identified, and either fixed, or cbuild is extended to mitigate them. Feedback is taken into account. Everything is cbuild. One tool does everything, in a streamlined way. Managing the repository, the build environment, the repo generation and signing, even parts of the VCS handling and common maintenance tasks. No external helper stuff. The remote build infrastructure just runs cbuild and not much else.

这隐含了一些要求（我会尽力让内容易于理解，遗憾的是岁月留下了痕迹，我可能把一些假设视为理所当然，所以请多多包涵；这也适用于后面的章节）：每个人都使用相同的工具。低效的用户体验模式会被识别出来，要么被修复，要么通过扩展 cbuild 来缓解。反馈会被纳入考量。一切皆为 cbuild。一个工具以精简的方式完成所有事情。管理仓库、构建环境、仓库生成和签名，甚至包括部分版本控制系统（VCS）的处理和日常维护任务。没有外部辅助工具。远程构建基础设施只运行 cbuild，几乎不运行其他东西。

The tooling does much of the bulk of making sure your packaging is correct and clean, most issues are hard errors. Heavy sandboxing, build environment consistency, unit tests by default, etc. You can run it on any Linux. If you run it on Chimera, you can immediately test your work. You can take the repo and bring it somewhere else. That also means the builder machines in the remote infra can run anything.

该工具承担了确保打包工作正确且整洁的大部分繁重工作，大多数问题都会被视为严重错误。它具备严格的沙盒机制、构建环境一致性、默认单元测试等。你可以在任何 Linux 上运行它。如果你在 Chimera 上运行，你可以立即测试你的工作。你可以将仓库带到其他地方。这也意味着远程基础设施中的构建机器可以运行任何东西。

Chimera is a collective effort. You are expected to share the stuff you make, and get it upstreamed to us. The tooling is not intended for local things that won’t get shared, and it provides no guarantees or obligations for such usage; cbuild is a developer tool, not a user tool. But every user can be a developer. The tooling should easy and straightforward to use, and fun. It should not make things hard for you. Every user can be a maintainer. It shouldn’t be unnceessarily intimidating. We don’t gatekeep here when possible. You should also be having fun using the system and being here.

Chimera 是集体努力的成果。我们期望你分享你的成果，并将其提交给我们。该工具并非为不会分享的本地事务而设计，对于此类用途也不提供任何保证或义务；cbuild 是开发者工具，而非用户工具。但每一位用户都可以成为开发者。该工具应该易于使用、直观且有趣。它不应该给你制造困难。每一位用户都可以成为维护者。它不应该让人感到不必要的畏惧。在可能的情况下，我们不会设置门槛。你应该在使用该系统和身处此地时感到快乐。

You can replicate the entire remote infrastructure of the project on your machine in an hour or something. You can replicate the heavy bulk of things in like 5 minutes. The way things work is supposed to steer you towards implicitly doing the right thing, and punish incorrect patterns by making them harder than the correct ones. E.g. it’s really difficult or impossible to manually patch files with regex, or to do internet-reaching stuff during the build, or to touch the build environment filesystem.

你可以在一小时左右的时间内在你的机器上复制整个项目的远程基础设施。你可以在大约 5 分钟内复制大部分核心内容。其工作方式旨在引导你隐式地做正确的事情，并通过使错误模式比正确模式更难操作来惩罚它们。例如，手动使用正则表达式修补文件、在构建期间进行联网操作或触碰构建环境文件系统是非常困难甚至不可能的。

It’s really easy to manage patches though, there are build styles for common build systems, there are fine grained utility modules for doing all sorts of common annoying things, etc.; the tooling also automatically checks your stuff for correct formatting and other lint issues, validates your dependencies, validates your metadata including minor things like whether your build dependencies are sorted correctly and whether the SPDX license expression is correct and lost of other nits, and so on. Extensive documentation for the build system and packaging.

不过，管理补丁非常容易，有针对常见构建系统的构建样式，有用于处理各种常见烦琐事务的细粒度实用模块等；该工具还会自动检查你的内容格式是否正确以及是否存在其他代码检查问题，验证你的依赖项，验证你的元数据（包括构建依赖项是否排序正确、SPDX 许可证表达式是否正确等细微事项），等等。构建系统和打包工作有详尽的文档。

A common workflow setting up everything from scratch would look like so: $ # set up environment with your cports fork $ git clone https://github.com/my-user/cports $ cd cports $ # prepare a signing key $ ./cbuild keygen $ # prepare a build environment $ ./cbuild bootstrap $ # write your template here; then build it $ ./cbuild pkg user/my-cool-program $ # make a branch for submission $ git checkout -b my-cool-program $ # automatically makes a commit with the correct message and all files included $ ./cbuild commit user/my-cool-program $ # push and publish PR with the link $ git push origin my-cool-program

从零开始设置一切的常见工作流程如下： $ # 使用你的 cports 分支设置环境 $ 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 $ # 推送并发布带有链接的 PR $ git push origin my-cool-program

An update would be done like this: $ ./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 $ git push

更新操作如下： $ ./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 $ git push

The tooling provides common utilities for keeping your local repository clean, e.g. pruning packages and so on; it provides maintenance tools for bumping versions and revisions, checking dependency graphs, checking for new versions via update-check (which for most things distributed e.g. via common git forges requires no extra effort or specialized code), checking if your local repository can be unstaged against the remote one (verifying if you really rebuilt everything that needs it), updating sha256 checksums in templates. It even supports custom template-specific actions, such as building bootstrap tarballs for compilers. It supports aliases for less typing.

该工具提供了用于保持本地仓库整洁的常用实用程序，例如清理软件包等；它提供了用于提升版本和修订号、检查依赖关系图、通过 update-check 检查新版本（对于大多数通过常见 git 平台分发的项目，这不需要额外的工作或专门的代码）、检查本地仓库是否可以与远程仓库同步（验证你是否确实重新构建了所有需要的内容）、更新模板中的 sha256 校验和的维护工具。它甚至支持自定义的模板特定操作，例如为编译器构建引导 tarball。它支持别名以减少输入。

Checking for if a package has an update: $ ./cbuild update-check main/firefox main/firefox: 157.0 -> 157.0.1

检查软件包是否有更新： $ ./cbuild update-check main/firefox main/firefox: 157.0 -> 157.0.1

It supports fun things when it comes to packaging bulk batches. For instance, it integrates git: $ # build everything changed in your local commits $ ./cbuild bulk-pkg git:origin/master..HEAD $ # build a specific commit $ ./cbuild bulk-pkg git:commithash $ # build a range of commits but skipping stuff that has “test” in commit message $ ./cbuild bulk-pkg git:from..to+!test

在批量打包方面，它支持一些有趣的功能。例如，它集成了 git： $ # 构建本地提交中所有更改的内容 $ ./cbuild bulk-pkg git:origin/master..HEAD $ # 构建特定提交 $ ./cbuild bulk-pkg git:commithash $ # 构建一系列提交，但跳过提交消息中包含 “test” 的内容 $ ./cbuild bulk-pkg git:from..to+!test

It supports common stuff, like $ # build everything you have in your local repo that has a newer cports version $ ./cbuild bulk-pkg status:outdated

它支持常见操作，例如： $ # 构建本地仓库中所有有更新 cports 版本的内容 $ ./cbuild bulk-pkg status:outdated

There is a lot more that I could mention. I also wanted to talk about how we got here, how we started, and how our infra works. Personal history I started using Linux in 2006/7 and soon ended up on Debian as my long-term operating system. Around the same time I started to seriously get into programming and the intersection of that ended up being packaging for

我还可以提到很多其他内容。我还想谈谈我们是如何走到这一步的，我们是如何开始的，以及我们的基础设施是如何运作的。个人历史：我是在 2006/7 年开始使用 Linux 的，很快就选择了 Debian 作为我的长期操作系统。大约在同一时间，我开始认真学习编程，而这两者的交集最终变成了为……进行打包。