Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Bobr

bobr

Bobr is a content-addressed build system for Linux. It executes a request — a DAG of recipe nodes — and produces objects such as filesystem trees and root-filesystem images.

The accompanying recipe collection builds Linux kernels, initramfs images, and complete root filesystems from declarative Nickel recipes. It also provides helpers for booting the resulting systems under QEMU.

Website and documentation: bobr.build.

Try Bobr

On x86-64 Linux, install the latest release with:

curl -fsSL https://bobr.build/install.sh | bash

Then follow Build and boot a QEMU system. With the public repository of prebuilt objects, the initial download normally takes about 1–2 minutes, depending on the connection.

Watch the terminal demo

Installing Bobr, downloading three QEMU boot artifacts from the public repository, and booting the guest

The installer verifies the release checksum and installs into ~/.local/bin. See Installation for a review-before-running variant, custom destinations, prerequisites, and uninstallation.

Current status

Bobr is under active development and currently targets native x86-64 Linux. Development has so far focused on the build system itself; the included guest systems remain proof-of-concept demos.

Key properties

Every object — a fetched source or a build result — is named by the hash of its content and kept in a content-addressed store. Identical results are deduplicated and reused across builds, so a request rebuilds only what is actually missing and serves everything else from the store. Reproducible builds with the same inputs produce the same content-addressed object. Filesystem trees are assembled by hard-linking files into place, not copying — so they build fast and cheap.

Builders run in Linux user-namespace sandboxes with an explicit root filesystem and a controlled environment, so a build cannot silently depend on the host. Sources are pinned by content hash (HTTP fetches support mirror fallback). A handful of composable builders cover the common needs — assembling and transforming filesystem trees, and extracting OCI images — and a sandbox builder runs arbitrary build steps, from compiling a package to packing a tree into a bootable image. Recipes are written declaratively (in Nickel) and lower to the JSON request bobr executes.

Bobr addresses some of the same system-construction problems as Yocto, but keeps recipes in a separate Nickel layer with contracts and Nix-style overlays. Yocto is centered on cross-compilation for embedded targets; Bobr currently builds ordinary systems natively.

Like Nix, Bobr provides hermetic builds, hash-keyed storage, and extensive reuse. Unlike Nix, Bobr does not prescribe a Nix-style filesystem layout: filesystem structure is selected by recipes. This makes conventional layouts possible, at the cost of not keeping several package versions side by side in the resulting system. Bobr is content-addressed from the start, whereas Nix store paths are input-addressed and content-addressed derivations remain experimental.

Bobr borrows ideas from OSTree — a content-addressed store and an immutable read-only rootfs. But OSTree is about delivering and updating that OS on the machine (atomic upgrades and rollback), where Bobr builds the images.

Bobr HostBundles are a proof of concept for container-like portability without a container runtime. Their practical viability still needs to be evaluated.

Independence and Affiliation

This is a personal open-source project, developed independently rather than derived from an existing codebase. It is not affiliated with or endorsed by Qualcomm or any other organization.

License

Licensed under either of

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Documentation

  1. Installation Host requirements, release installation, PATH setup, and uninstallation.

  2. Getting Started Build and boot QEMU systems, reuse results from a local store, customize the package set with overlays, and write recipes for local sources.

  3. Concepts The ideas bobr is built on — content addressing, objects, keys, and recipes — and how a build runs. The mental model behind the reference docs.

  4. Filesystem trees How bobr represents filesystem trees as content-addressed objects: manifests, shared files, and materialization.

  5. Request The request format: the source and builder recipe shapes, the builders, and the source origins.

  6. Recipes in Nickel Authoring recipes in Nickel instead of raw JSON: the package set, overlays, build/runtime dependencies, split outputs, and synthetic builders that expand into a request.

  7. HostBundle Building verified, relocatable host-side application directories: payloads, launchers, wrappers, typed environment, startup verification, and runtime behavior.

  8. Store Content-addressed store, build identity, canonical object records, reuse mappings, and name refs.

  9. Remote repositories Publishing complete stores as authenticated content-addressed caches: signed masters, immutable indexes and content, slot retention, the bobr-repo administration workflow, and garbage collection.

  10. Build logging Logging channels, store-log layout, the structured event record, the closed status vocabulary, and the format guarantees.

  11. Filesystem Object Hashing Structural hashing rules shared by filesystem paths and tar archives.

  12. fs-tree Manifest Canonical manifest format for manifest-addressed fs-tree artifacts.

  13. Development Working on bobr rather than with it: building from a source checkout, and rebuilding the world into a fresh store.

  14. Scheduler Demand-driven DAG realization, exact and reuse resolution, Source acquisition, builder execution, concurrency limits, and cancellation.

  15. TODO Major planned improvements.