Package repository · Provenance
Saphira v0.1
The first Dragon. Wrought in the forge, now able to keep its own fire and begin the next turn of the circle.

What emerged from the forge
Saphira v0.1 is what came out the other side of the chain described on the Forge: SDK to Stage 0 to Stage 1 to Stage 2 to Stage 3 to Stage 4 to final assembly. A QCOW2 image that boots, not a cross compiled snapshot and not a repackaged Arch root. That image began as AKADATA Linux with x86_64-akadata-linux-musl and all released Saphira flavours now use x86_64-saphira-linux-musl, x86-64-v3 baseline, musl's ld-musl-x86_64.so.1 in /lib, and the whole userspace linked against it.
That is the test a from scratch distro must pass: disconnect the builder and see if the system still reaches a login prompt on its own kernel and its own libraries. Saphira v0.1 did. Everything before this page explains how it was created. Everything after this page explains how an already running Saphira learned to create its successor. The circle turns here.
A small system with opinions
v0.1 is deliberately small and opinionated. The choices that make Saphira recognisable were present from the first boot:
- musl libc as the only libc, no glibc in the runtime.
- Non usr merged:
/bin,/sbin,/usr/bin,/usr/sbinremain distinct. Early OpenRC lives in/sbin. - APK for packages, OpenRC with
openrc-initas/sbin/init, and the same base can boot systemd as Saphira D. A systemd boot can still fall back to/sbin/openrc-rununtil the OpenRC scripts are removed. One body, two ways to wake it. - Deterministic: fixed
SOURCE_DATE_EPOCH, pinned sources, fingerprints that invalidate cleanly. - One base, two inits: Saphira Linux (OpenRC) and Saphira D (systemd) share the same musl userspace and triple
x86_64-saphira-linux-muslwhich replaces the originalx86_64-akadata-linux-musl.
None of this was a retrofit. The bootstrap enforces it from Stage 1. A package violating it does not get a warning, it fails. The bones were set before the Dragon learned to walk.
Why v0.1 matters
v0.1 is the point where the story stops being about a builder host and starts being about a host of its own. Until then, every tool was borrowed: Arch's kernel, Arch's paths, the build directory. From v0.1 on, Saphira has a root filesystem of its own, one that can be copied, booted, and later asked to compile the next Saphira. The parent is no longer needed for warmth.
The dragon language finally earns its keep here. A forge can make many things. A dragon is something that, once hatched, keeps its own fire. That turn from made thing to living system is the whole circle of life in one step, and it is why v0.1 is the root of everything that follows.
Before there was an Egg
Egg did not create the first Saphira. Egg was already running Saphira.
After v0.1 booted, one running Saphira system was given a new role: to act as the native build controller, to replace bootstrap residue with proper package ownership and to begin producing the next generation from inside Saphira itself. That system became Egg. Egg is not the origin. It is the handover, the nest that holds the next egg.
Egg in turn incubated Hatchling, and Hatchling proved the packages that would hatch into Hatched, the first Saphira D running systemd on musl. One Dragon made an Egg, the Egg made a Hatchling, the Hatchling became a Dragon again. The same Saphira base turned through OpenRC and systemd without changing what it is. The details of that continuing circle are told on the later pages so this page can do one thing honestly: mark the moment the forge's work became a running system. If you came to understand provenance, you can stop here and have the answer. If you came to follow what happened next, Egg is the next step.