| 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:41`, not `FROM ghcr.io/ublue-os/main`. That's what "alongside ublue, not downstream" resolves to in practice.
|
|
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:42`, not `FROM ghcr.io/ublue-os/main`. That's what "alongside ublue, not downstream" resolves to in practice.
|
| 30 |
30 |
|
|
| 31 |
31 |
|
### "Install Silverblue and run our script" (non-option)
|
| 32 |
32 |
|
|
| 50 |
50 |
|
|
| 51 |
51 |
|
### Registry: `quay.io` (deferred until distribution starts)
|
| 52 |
52 |
|
|
| 53 |
|
- |
Red Hat's container registry is the intended destination once Alloy has an image worth distributing. Free for public images, ecosystem-coherent with the `quay.io/fedora/fedora-bootc:41` base.
|
|
53 |
+ |
Red Hat's container registry is the intended destination once Alloy has an image worth distributing. Free for public images, ecosystem-coherent with the `quay.io/fedora/fedora-bootc:42` base.
|
| 54 |
54 |
|
|
| 55 |
55 |
|
**Current state:** no registry provisioned. `.builds/alloy-image.yml` runs a **build + lint smoke test** only — validates the Containerfile on every push, without publishing anywhere. When the image is worth distributing, the CI file grows back `sign` and `push` tasks and `quay.io/alloy/alloy` gets provisioned with a robot account.
|
| 56 |
56 |
|
|
| 64 |
64 |
|
|
| 65 |
65 |
|
The Containerfile at the repo root (see `Containerfile`) sketches:
|
| 66 |
66 |
|
|
| 67 |
|
- |
1. **Base:** `FROM quay.io/fedora/fedora-bootc:41`.
|
|
67 |
+ |
1. **Base:** `FROM quay.io/fedora/fedora-bootc:42`.
|
| 68 |
68 |
|
2. **Third-party repos:** Tailscale, any COPRs Alloy depends on for packages not in Fedora main.
|
| 69 |
69 |
|
3. **Package additions:** the full Alloy stack from [STACK.md](STACK.md) — compositor, bar, launcher, notifications, terminal, editor, shell, viewers, utilities, continuity daemons, fonts, themes.
|
| 70 |
70 |
|
4. **Package removals:** stock Silverblue desktop pieces Alloy replaces (gnome-shell, gdm — the latter gated on the greeter pick).
|
| 86 |
86 |
|
|
| 87 |
87 |
|
## Fedora version tracking
|
| 88 |
88 |
|
|
| 89 |
|
- |
Pinned to `:41` explicitly. Bumps to `:42` are a deliberate act — Alloy tests the new base, updates the Containerfile, ships. Not automatic. This is the "correctness over deadline" pattern applied to base tracking.
|
|
89 |
+ |
Pinned to `:42` explicitly. Bumps to `:43` and beyond are a deliberate act — Alloy tests the new base, updates the Containerfile, ships. Not automatic. This is the "correctness over deadline" pattern applied to base tracking.
|
| 90 |
90 |
|
|
| 91 |
91 |
|
## Open questions
|
| 92 |
92 |
|
|
| 94 |
94 |
|
- [ ] `bootc-image-builder` for ISO generation. First-time-user path is `bootc install` from a live environment; the ISO is what makes that a smooth experience. Verify the ISO builder handles Alloy's specific package set.
|
| 95 |
95 |
|
- [ ] Single-stage vs. multi-stage Containerfile. Single-stage until rebuild time hurts.
|
| 96 |
96 |
|
- [x] sr.ht account: **`~maxmj`** for v0. LLC-owned `~makecreative` remains the long-term target; migration if/when the project grows.
|
| 97 |
|
- |
- [ ] Whether to publish `:latest`, `:41`, and `:41-YYYYMMDD` tags. Recommend all three — `:latest` for casual users, `:41` for version-pinned users, `:41-YYYYMMDD` for reproducibility.
|
|
97 |
+ |
- [ ] Whether to publish `:latest`, `:42`, and `:42-YYYYMMDD` tags. Recommend all three — `:latest` for casual users, `:42` for version-pinned users, `:42-YYYYMMDD` for reproducibility.
|