tine: 부팅 가능한 이미지를 만드는 새 빌드 시스템

Sep 24, 2026 13 min read From Thin Air to Bootable Images: The tine Build System By Daan De Meyer and Martin Pitt Table of contents This post is part of a series covering some of the open source work we have been doing in recent months. Today we introduce and publish tine , our new Buck2-based build system. Our Requirements Building an operating system with cryptographically verifiable integrity has to start with a build system with these very properties. At the same time, we are part of the greater open source community and want both to contribute and re-use as much existing work as possible. We also aim for efficient development with fast turnaround. This roughly translates into the following requirements for our build system: Minimal host requirements. It must be self-contained and must minimize external dependencies, so that it can be run in any environment. Full control over inputs. It must allow pinning every piece of software that goes into a product. It must support a choice of upstream distributions (Fedora, CentOS, Arch, Debian, etc.) and reuse existing packages where possible, while still making it easy to react quickly to CVEs and to diverge (either temporarily or permanently) from upstream packaging decisions when necessary. Integrated package machinery. It must provide tooling for importing, updating, and merging imported packages. Cheap world rebuilds. It must be able to rebuild the world on demand, e.g. after a gcc bump. Hermetic, reproducible builds. All component and image builds must run in a hermetic environment and produce bitwise reproducible output. Native image builds. It must be able to build bootable operating system images and systemd sysext images natively and concurrently. Monorepo-based iteration. It must support maintaining the operating system in a single top-level monorepo for fast end-to-end iteration. A change to an imported rpm or to a Go or Rust component must be immediately buildable and testable across the full set of images, without intermediate commits or pushes and without elaborate version or dependency declarations. First-class custom components. It must natively and efficiently build Go and Rust projects from pinned external repositories, for example kubernetes or varlink-http-bridge . Scanner compatibility. Built images must work with standard SBOM tooling and security scanners such as syft / grype or trivy . Caching. Builds must be able to retrieve unchanged components from a local and/or global cache. Building everything from scratch can take hours, and a developer is usually only working on a single component. Existing Tools Before building our own build tool, we evaluated several options. mkosi Given our team includes the creator and maintainer of mkosi , it was a natural first candidate to evaluate. But we quickly came to the conclusion that it has some fundamental shortcomings. It’s great at building individual images based on upstream packages, but becomes restrictive when building several weakly related images or if you need more control over the artifacts that make up an image. Building multiple images is limited to images that are intended to be shipped as part of the “main” image. We need to build many different kinds of artifacts in a uniform and robust way, not just images. Hence the build needs to be orchestrated by a generic and flexible tool. The main build file should be a language calling into library functions like “compile a cargo crate” or “build a UKI ”. mkosi is the opposite, it’s a framework : It knows how to build images, and only gives you free-form opaque hooks for the other kinds of builds. That leads to a bad experience when you want to build more than just images. Open Build Service The Open Build Service (OBS) is a powerful fully-integrated build system that is primarily used by SUSE and the openSUSE project to produce all of their artifacts, anything from packages to ISOs, and many other image formats. It has strong dependency tracking and supports a dizzying array of distributions. However, it’s also the antithesis of “minimal host requirements”. The server side of it is required, central, and non-trivial to self-host. It’s also not a generic build system, meaning any new artifact types would either have to be modelled as packages or require heavy patches to OBS. We concluded that this lack of flexibility combined with its overall architecture would make it difficult for OBS to meet our requirements. BuildStream Apache BuildStream describes the operating system image as a graph of YAML "elements", each with its own sources, dependencies and build commands. BuildStream builds each one in a bubblewrap sandbox and caches the result under a hash of everything that went into it, similar to Buck2. It is mature and used to build freedesktop-sdk , GNOME OS , and WebKitGTK . Our concerns with BuildStream are mostly around bootstrapping and extensibility. BuildStream is a Python application with compiled extensions and other dependencies. It relies on a separate set of helper programs, plus sandboxing tools from the host. Each of those can be pinned, but through different mechanisms, and even then the result still depends on the host's Python. In practice you run it from a pinned container image instead, but then you’re still dependent on an entire container runtime you don’t control. BuildStream’s YAML is a plain data format, and is extended with Python plugins. YAML has no functions, so over time you end up copy-pasting across the project. Ultimately we decided to go for a tool with a better bootstrapping and pinning story as well as a more flexible language. Antlir Antlir is Meta's OS image builder, built on top of the Buck2 build system engine. Buck2 is Meta's open source build system with emphasis on correctness, flexibility, and caching as much as possible. Antlir implements various rules for building images with Buck2. As Antlir is a high-level tool focused on Meta’s internal repository, it is naturally very opinionated and designed for Meta’s internal use cases. For example, it requires btrfs and is strongly focused on a single monorepo. While we decided against using Antlir itself, its underlying engine, Buck2, turned out to be a good fit, and we ended up choosing it as the foundation for our own build system. Our Build System: tine In essence, tine is a set of opinionated Buck2 rules to build rpm, Rust crate and Go module components, UKIs , and images; it can sign images either with a hardware key through PKCS#11 or a locally generated key. The intent is to combine the best ideas from Antlir and mkosi into a single tool. tine has only three requirements on its build host: git, python3 (just for its own bootstrapping, not for production builds) and user namespaces. From there, it bootstraps everything it needs from pinned declarations to get a reproducible and independent build environment. That can be a distribution as old or modern as you need. An important tine concept is the “ box ”, which is a declared and pinned down environment to run a build task. Think containers or distrobox , but declared natively in Buck2’s language, and using Buck2’s caching and rebuild rules, so they build quickly and naturally, stay reproducible, and need no further dependencies to run. tine itself defines boxes for running rpmbuild, go, or cargo, or a bigger multi-purpose one called fedora.rawhide.box which contains e.g. systemd-ukify for building images and QEMU for running virtual machines. Your own project can define its own boxes. tine’s Engine: Buck2 To better understand this post and the examples, here is a one-minute Buck2 primer for those familiar with Make or Meson : Build file: A BUCK file is the directory's Makefile equivalent. It's written in a Python dialect called Starlark , and declares all targets that you can build. Cell: A named build graph root; these roughly follow the boundaries of git repositories: // is your own top-level project (the OS you