| 1 |
1 |
|
# Image composition
|
| 2 |
2 |
|
|
| 3 |
|
- |
How Alloy is built and delivered. bootc + Containerfile, source on `makenot.work`, built locally and natively, container image on `quay.io` when distribution starts. Companion to [STACK.md](STACK.md).
|
|
3 |
+ |
How Alloy is built and delivered. bootc + Containerfile, source on `makenot.work`, built locally and natively, and **no image published anywhere, ever** (decided 2026-07-30, see "Registry" below). Companion to [STACK.md](STACK.md).
|
| 4 |
4 |
|
|
| 5 |
5 |
|
## Landscape
|
| 6 |
6 |
|
|
| 26 |
26 |
|
|
| 27 |
27 |
|
Universal Blue's convention is exactly the bootc + Containerfile pattern above, using `FROM ghcr.io/ublue-os/main`. Battle-tested. But being downstream of ublue means inheriting ublue's opinions and coupling to their release cadence, which [STACK.md's Base section](STACK.md#base) explicitly rejects.
|
| 28 |
28 |
|
|
| 29 |
|
- |
**The nuance:** Alloy uses the ublue-style *convention* (Containerfile, OCI registry, CI-driven build) *without* using ublue's base image. `FROM quay.io/fedora/fedora-bootc:43`, not `FROM ghcr.io/ublue-os/main`. That's what "alongside ublue, not downstream" resolves to in practice.
|
|
29 |
+ |
**The nuance:** Alloy takes the ublue-style *convention* (a Containerfile over a bootc base) without ublue's base image: `FROM quay.io/fedora/fedora-bootc:43`, not `FROM ghcr.io/ublue-os/main`. That is what "alongside ublue, not downstream" resolves to in practice.
|
|
30 |
+ |
|
|
31 |
+ |
This line used to say the convention included an OCI registry and a CI-driven build. It does not, and that is where Alloy parts company with ublue rather than a detail of it: ublue's whole model is a published image somebody else builds for you, and Alloy's is source you build yourself. quay.io appears in this repo in exactly two places, both `FROM` lines pulling Fedora's own bases, and nothing is ever pushed there.
|
| 30 |
32 |
|
|
| 31 |
33 |
|
### "Install Silverblue and run our script" (non-option)
|
| 32 |
34 |
|
|
| 129 |
131 |
|
- [ ] **An always-on x86_64 builder.** The blocker under "CI" above, and the thing the signing key and the weekly base-update rebuild both wait on. astra is always-on and aarch64; fw13 is x86_64 and sleeps.
|
| 130 |
132 |
|
- [ ] **Language toolchains selected per image rather than for everyone.** The Rust toolchain went into the base on 2026-07-26 because Alloy's audience is developers and because the build-host role needs cargo present (sandod compiles in its own workdir and will not run without it). It costs 610 MiB installed, which is the largest single line in the package block and roughly twelve times the hardware-health group. One number for every install is the wrong shape as soon as a second language is wanted: a Go or Python or C toolchain each carries a comparable bill, and no machine wants all of them. Minting is where this resolves, since a per-machine image is already being produced with a baked key, so the toolchain set is another mint-time input rather than a new mechanism. Open: whether the base keeps Rust as the default when selection exists, or drops to none and makes every toolchain a choice. See [[alloy-image-minting]].
|
| 131 |
133 |
|
- [x] Source hosting: **`makenot.work/git/max/alloy`**, our own platform. The old answer here was the sr.ht account `~maxmj` for v0 with LLC-owned `~makecreative` as the long-term target; sourcehut is now a backup remote and that migration question retires with it.
|
| 132 |
|
- |
- [x] **Publish `:latest`, `:<fedora-version>`, and `:<fedora-version>-YYYYMMDD` tags.** Currently `:latest`, `:43`, `:43-YYYYMMDD`. `:latest` for casual users, the bare version for version-pinned users, the dated tag for reproducibility. Wired up when distribution starts.
|
|
134 |
+ |
- [x] ~~**Publish `:latest`, `:<fedora-version>`, and `:<fedora-version>-YYYYMMDD` tags.**~~ **Struck 2026-08-06.** A tagging scheme is a publishing question and nothing is published, so there is nothing for it to name. The local build tags `localhost/alloy:local` and a machine adopts it with `bootc switch --transport containers-storage`; reproducibility comes from the source and the pinned base digests rather than from a dated tag. Kept as a struck line rather than deleted, because the scheme reads as an obvious thing to want and this is the answer to whoever proposes it next.
|