qorpa D8: el pin fija el suelo, no la instancia; y la terna curada

Faltaba decir en el ADR lo que se confunde solo: "pinear" no significa que la
imagen no se actualice. El digest es la IDENTIDAD, igual que en el rootfs del
lab. Lo que se pinea es el suelo; lo que instalás adentro con dnf/pacman ni
está pineado ni puede estarlo, y se actualiza normal.

Subir la base de versión es barato PRECISAMENTE por D3: manifiesto = verdad,
upper = caché ⇒ cambiar el digest y recrear. Y el riesgo del pin (que upstream
borre el tarball) ya lo resolvió ADR 0013: la URL no entra en la identidad,
sólo el sha256, así que espejar es gratis.

Curaduría decidida con el usuario — TRES, cada una por un trabajo distinto:
- Arch bootstrap (juegos: multilib 32-bit y SteamOS es Arch ⇒ extiende D6),
- Ubuntu base LTS (binarios comerciales: es contra lo que se compilan),
- Steam Runtime sniper (la única SELLABLE: inmutable ⇒ file_drop al store).
Fedora queda BYO: hace el mismo trabajo que Arch en el slot "fresco" y una
tercera cadena mutable es la normalización que §NO-resuelve 3 quiere evitar.

Los pines de las dos primeras están VERIFICADOS contra upstream hoy (Arch
2026.09.01 sha 895661bd…, Ubuntu 24.04.3 sha 6bc2cde3…); el de sniper NO, y se
dice que no en vez de suponerlo.

Y queda anotado que hacerlas compartibles más adelante no pide diseño nuevo:
una imagen pineada es cuerpo inmutable direccionado por contenido ⇒ ADR 0014
se le aplica tal cual. Lo único que hay que mirar antes de publicarlas a
terceros es licencia y marca, que no es una pregunta técnica.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U5cQtQrYNjWJVXVE6aEpQ2
This commit is contained in:
Sergio
2026-09-03 03:39:36 +00:00
co-authored by Claude Opus 5
parent 9a7e7bc17f
commit d8778e4dd9
+46
View File
@@ -235,6 +235,52 @@ se compila al mismo `PolicySpec` que ya consume `harkaq-exec`.
Un `dnf` que no alcanza `~/.ssh` es un argumento que ninguna distro ofrece.
### D8 — Qué se pinea (el suelo, no la instancia) y cuántas imágenes se curan
Dos preguntas que se confunden y tienen respuestas distintas.
**a) Pinear no congela: fija el punto de partida.** El digest ES la identidad, igual que
`alpine-minirootfs`, `zig` y el rootfs del lab. Lo que queda dentro y fuera del pin:
| qué | ¿pineado? | cómo se actualiza |
|---|---|---|
| el rootfs base | **sí**, por sha256 | cambiar el digest en `instancia.toml` + `hammer qorpa recrear` |
| lo que instalás adentro (`dnf install steam`, `pacman -Syu`) | **no, y no puede estarlo** | con el gestor de la imagen, cuando quieras |
Subir la base de versión es barato **precisamente por D3**: como el manifiesto es la verdad y el
`upper/` es caché, se cambia `base = "sha256:…"` y se recrea. Sin D3 sería un rebase sobre un blob
irreemplazable; con D3 son dos líneas y un rato de red.
El riesgo real del pin —que upstream borre el tarball— **ya está resuelto por
[ADR 0013](0013-mirror-de-fuentes.md)**: la URL no entra en la identidad, sólo el sha256, así que
espejar una imagen es gratis y una imagen pineada no se puede perder.
**b) Pinear ≠ lista cerrada.** `hammer qorpa traer <url> --sha256` acepta cualquier rootfs. Lo corto
no es lo que *se puede* traer, sino lo que **nosotros probamos, espejamos y publicamos**, porque cada
imagen curada es una segunda cadena de suministro que hay que sostener (§NO-resuelve 3). Se curan
**tres**, y cada una entra por un trabajo distinto — no por sabor:
| imagen | tipo | qué trabajo hace | pin (verificado 2026-09-03) |
|---|---|---|---|
| **Arch bootstrap** | 1 | juegos: `multilib` de 32 bits de primera clase, y SteamOS *es* Arch ⇒ extiende el argumento de D6 («la configuración exacta que Valve prueba») | `archlinux-bootstrap-2026.09.01-x86_64.tar.zst`, sha256 `895661bd…`, en `archive.archlinux.org` (archivado para siempre) |
| **Ubuntu base LTS** | 1 | binarios comerciales: Zoom, Slack, Discord, Spotify, Chrome, JetBrains se compilan y prueban contra esto | `ubuntu-base-24.04.3-base-amd64.tar.gz`, sha256 `6bc2cde3…`, `cdimage.ubuntu.com` + `old-releases` |
| **Steam Runtime «sniper»** | 2 | la única **sellable**: al no mutar entra al store por `file_drop` y su digest va al índice firmado — cadena de custodia nuestra | ⚠ pin sin verificar todavía |
**Fedora queda BYO, no curada.** No por calidad —publica `Fedora-Container-Base-Generic-43-1.6`
con CHECKSUM firmado y se pinea igual de bien— sino porque hace el **mismo trabajo que Arch** en el
slot «fresco», y una tercera cadena mutable es justo la normalización que §NO-resuelve 3 quiere
evitar. El ejemplo de D3 sigue diciendo `fedora-43` a propósito: el mecanismo no distingue, y eso es
la demostración de que la terna es una decisión de curaduría, no del diseño.
**c) Compartibles, más adelante.** Una imagen pineada es cuerpo inmutable direccionado por
contenido, así que **[ADR 0014](0014-distribucion-multiorigen.md) se le aplica sin cambiar nada**:
puede servirse desde cualquier origen porque el digest la verifica, y ausencia ⇒ seguir mientras que
contenido distinto ⇒ ABORTAR. No se hace el día uno, pero no hay que diseñar nada para que se pueda:
lo único que falta es la decisión. ⚠ Antes de publicarlas a terceros (no a nuestras propias
máquinas, que es lo que ya hace ADR 0013 con las fuentes) hay que mirar licencia y **marca**:
redistribuir un rootfs de Ubuntu o Fedora sin modificar suele estar permitido, pero la política de
marca es cosa aparte y no es una pregunta técnica.
---
## Lo que este ADR admite que NO resuelve