Diagnóstico completo. No es daño de la campaña del split ni un fallo de store-gc. LO MEDIDO, en orden: 1. 86 nodos del perfil sin artefacto en su hash vigente. 2. NO lo causó el split: revertidas una por una todas las recetas tocadas hoy (3 bibliotecas base, 30 hojas, dbus, 38 de la 2ª tanda) el número NO se movió de 198 en ningún caso. 3. La FRONTERA son 7 recetas —las únicas cuyas deps sí están al día—: dbus, libnl, libpcap, libxkbcommon, lm-sensors, perl-xml-parser, vulkan-loader. Las otras 79 cuelgan de ellas. 4. Las 7 son SOMBRAS de incoming-kde, no las canónicas. Las del corpus están al día, y por eso el problema es INVISIBLE desde el grafo del corpus — que es justo el que yo miraba. 5. No fue store-gc: sus hashes vigentes no figuran en ningún manifiesto de borrado, y tres nunca se podaron. (Lo sospeché porque la regla de «superado» es por NOMBRE y una sombra comparte nombre con la canónica; la sospecha era razonable y los manifiestos la descartan.) 6. Ni el hub ni el worker los tienen. No están en otro sitio: NO ESTÁN. LA CAUSA DE FONDO, que importa más que KDE: la cola se construyó en workers EFÍMEROS, el sync del store es unidireccional (worker→hub) y esos workers ya no existen. Cuando algo del sustrato compartido cambió después, las sombras se re-hashearon y nadie las reconstruyó, porque el hub nunca fue la máquina donde vivía ese escritorio. ⇒ Con flota efímera y sync unidireccional, un escritorio puede dejar de ser reconstruible-desde-el-store SIN QUE NINGÚN INDICADOR LO DIGA. El grafo seguía reportando 162/162 desde un JSON generado semanas antes. Coste de arreglarlo: 86 reconstrucciones en la granja, empezando por las 7 de la frontera. No hay muro técnico conocido — son recetas que ya construyeron. Es cómputo, no investigación. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
350 lines
21 KiB
Markdown
350 lines
21 KiB
Markdown
# SDD 20 — El catálogo de lo que falta: hasta PUBLICABLE y hasta COMPLETA
|
|
|
|
Escrito 2026-08-07, a pedido del usuario: «el catálogo de todo lo que falta hasta decir *la distro
|
|
está publicable*, y lo de más hasta *la distro está completa*».
|
|
|
|
Este documento es el **inventario**. El [SDD 21](21-manual-del-piloto.md) es el **manual de a pie**:
|
|
qué tiene que hacer el usuario, en qué orden, en cada una de las tres etapas.
|
|
|
|
Todo lo de acá está **medido contra el repo el 2026-08-07**, no estimado de memoria. Donde hay un
|
|
número, hay un comando que lo produjo.
|
|
|
|
---
|
|
|
|
## Los dos codos, y por qué están donde están
|
|
|
|
- **PUBLICABLE** = un extraño puede descargarla, instalarla, usarla y actualizarla, y nosotros
|
|
estamos en regla al dársela. **No** significa que tenga todo lo que uno querría.
|
|
- **COMPLETA** = tiene lo que una persona espera de un sistema de escritorio para su día a día, sin
|
|
tener que salir a buscar nada fuera.
|
|
|
|
La distancia entre los dos codos es enorme y **el orden importa**: casi todo lo caro (navegador,
|
|
ofimática) está DESPUÉS del primer codo, y casi todo lo bloqueante (legal, claves, actualización)
|
|
está ANTES. La trampa clásica es invertirlos — pasarse meses con el navegador y descubrir el día del
|
|
anuncio que no se puede publicar.
|
|
|
|
---
|
|
|
|
# PARTE I — Hasta «la distro está PUBLICABLE»
|
|
|
|
## I.1 Estado de construcción: esto ya está casi cerrado
|
|
|
|
Medido con `docs/state/build-state*.json` (el grafo, no recuento a mano):
|
|
|
|
| frente | nodos | sellados | en deuda |
|
|
|---|---:|---:|---:|
|
|
| corpus | 771 | 759 | **12** |
|
|
| KDE | 968 | 952 | 12 |
|
|
| GNOME | 853 | 840 | 13 |
|
|
| COSMIC | 818 | 806 | 12 |
|
|
|
|
Los perfiles `base` (51 nodos) y `cli` (74 nodos) están **al 100%, deuda 0**.
|
|
|
|
> ⚠️ **CORREGIDO 2026-08-08.** Este párrafo decía «KDE cierra 162/162». **Falso**: regenerado el
|
|
> grafo, `escritorio-kde` está en **76/162**, y lo está en todos los commits recientes — o sea que ya
|
|
> lo estaba cuando se escribió esta frase. El error fue leer `docs/state/build-state-kde.json` **sin
|
|
> regenerarlo**: es un fichero GENERADO, y un generado que no se regenera es una foto vieja con
|
|
> aspecto de dato fresco. En total hay **198 recetas de las colas de escritorio** (KDE 133, GNOME 37,
|
|
> COSMIC 24) sin artefacto en su hash vigente.
|
|
>
|
|
> Se verificó que **NO lo causó la campaña del split** (SDD 23): se revirtieron una por una todas las
|
|
> recetas tocadas —las 3 bibliotecas base, las 30 hojas, `dbus`, las 38 de la 2ª tanda— y el número
|
|
> **no se movió de 198** en ningún caso.
|
|
|
|
**La deuda real es una sola lista de 12 recetas, compartida por todos los frentes** (por eso el
|
|
número se repite: es el mismo agujero visto desde cuatro grafos):
|
|
|
|
```
|
|
gtk4 libadwaita gtksourceview gtk4-hello adwaita-hello sourceview-hello
|
|
hammer-edit mirada-compositor mirada-greeter dwarves llimphi-counter wlr-randr
|
|
```
|
|
|
|
> ### ⚠️ CORREGIDO EL MISMO DÍA, MIDIENDO CONTRA EL WORKER
|
|
> La primera versión de esta sección decía que las 12 «fallan en el worker por su rootfs: `python
|
|
> OSError` en meson, `find_package` en cmake» y que el arreglo era declarar las herramientas en
|
|
> `[deps]`. **Se probó y es falso.** cmake y meson corren perfectamente en el worker. Las causas son
|
|
> **cuatro, distintas**, y ninguna es el rootfs. Se descubrió al construirlas de verdad en vez de
|
|
> heredar el diagnóstico.
|
|
|
|
**(a) Seis están bloqueadas por el muro del PIC — y el frente GNOME ya lo venció por otro camino.**
|
|
`gtk4` del corpus es `link = "static"` y enlaza `libfontconfig.a`, que tiene **1122 reubicaciones
|
|
no-PIC**: el enlace produce **13 032 errores** `relocation R_X86_64_64 cannot be used against local
|
|
symbol`. No es una receta rota, es una imposibilidad estructural. Mientras tanto
|
|
`recipes/incoming-gnome/gtk4.toml` —`link = "dynamic"` con las deps `-shared`— **está sellada**, y
|
|
con ella `libadwaita` y `fontconfig-shared`.
|
|
⇒ La cadena del corpus (`gtk4`, `libadwaita`, `gtksourceview`, `gtk4-hello`, `adwaita-hello`,
|
|
`sourceview-hello`, `hammer-edit`) es un **duplicado superado** de la cadena dinámica de GNOME.
|
|
Cerrarla no es «construirla»: es decidir si se **promueven las sombras `-shared` al corpus**, porque
|
|
la resolución de deps es hermano→padre y una receta del corpus no ve a las de `incoming-gnome`.
|
|
**Es una decisión de arquitectura, no una tarea** — y hay un aviso registrado de que promover a
|
|
ciegas hace que variantes homónimas pisen recetas canónicas.
|
|
|
|
**(b) `wlr-randr` — ✅ CERRADA HOY.** Le faltaban dos deps: `python3` (porque **meson es un script de
|
|
Python**; sin intérprete la fase muere con exit 127, que se lee como «meson no está») y `libffi`
|
|
(que la receta no usa: lo exige `wayland-client.pc` en su `Requires`). Auditadas las 1141 recetas,
|
|
era **la única** con meson y sin python3.
|
|
|
|
**(c) `dwarves` — frente propio, no deuda.** Falla porque nuestro `elfutils` entrega **sólo libelf**,
|
|
deliberadamente: libdw arrastra argp/obstack/fts, «lo verdaderamente difícil en musl». Y no se
|
|
arregla ampliando `elfutils`, porque de él cuelga **el kernel que ya reproduce bit a bit**; el camino
|
|
correcto es una receta aparte `elfutils-libdw`. Sin urgencia: ningún perfil lo pide y el kernel
|
|
desactiva `DEBUG_INFO_BTF` explícitamente por su ausencia. Se desbloquea cuando se quiera sched-ext.
|
|
|
|
**(d) `mirada-compositor`, `mirada-greeter`, `llimphi-counter` — HUB-ONLY estructural.** Su `source`
|
|
es `gitea@git.tawasuyu.net:...` por SSH y **el worker es sin secretos por diseño**. No es un fallo.
|
|
`llimphi-counter` ni siquiera llega a construir: su `commit` es literalmente ceros, con el comentario
|
|
«fijar al commit real» — es una receta sin terminar, y es de tawasuyu.
|
|
|
|
### Y el hallazgo de fondo: nadie las estaba intentando
|
|
El bucle del worker recorre `QUEUES="recipes/incoming recipes/incoming-go recipes/incoming-clib
|
|
recipes/incoming-gnome-onda1 recipes/incoming-gnome-onda2 recipes/incoming-gnome recipes/incoming-kde"`
|
|
— **el corpus (`recipes/`) no está en la lista**. Las 12 nunca se habían intentado en el worker. Buena
|
|
parte de «la deuda» era de encolado, no técnica.
|
|
|
|
## I.2 🚨 Lo legal — bloqueante
|
|
|
|
### Licencias: de 0 a 1063 de 1141 en un día
|
|
El 2026-08-07 se midió: **0 de 1141 recetas** declaraban licencia. (El informe previo decía «5 de
|
|
771»; los dos números estaban mal — los «5» eran falsos positivos de `grep license`: el paquete
|
|
`addlicense`, el paquete `cargo-bundle-licenses`, una línea de `install` y un comentario.)
|
|
|
|
Ese mismo día se hizo lo estructural:
|
|
- Campo `license` en la receta, **fuera de `hash_inputs`** ⇒ se puebla sobre recetas ya selladas sin
|
|
mover un solo `ArtifactHash`. Verificado en 40 recetas: 40 hashes idénticos, 0 cambiados.
|
|
- `scripts/licencias.sh` mide de verdad (cuenta el campo, no la palabra) y siembra desde una tabla
|
|
curada.
|
|
- Tabla curada por familias (toolchain, base C, gráficas, GNOME/GTK, Qt, KDE, X.Org, GnuPG,
|
|
freedesktop, kernel.org, PyPI) + el código propio de tawasuyu, que el usuario puso en **MIT**.
|
|
|
|
**Estado al cierre del día: 1063 de 1141 (93%).** Cuatro escalones de evidencia, de peor a mejor:
|
|
nombre (prohibido) → URL de fuente (familias) → API de licencias de GitHub → `Cargo.toml` del autor
|
|
al tag exacto. Faltan 78. **Falta también** desambiguar ~55 SPDX obsoletos (`GPL-3.0` no dice si es
|
|
`-only` u `-or-later`), que es trabajo humano: hay que leer cabeceras de fuentes.
|
|
|
|
El cierre definitivo, para que la deuda no vuelva a abrirse con cada receta nueva, es capturar la
|
|
licencia en la **fase de fetch**, que ya descarga y extrae cada tarball: ahí el dato pasa gratis.
|
|
|
|
⚠️ **La regla que no se rompe**: no se rellena a ojo. Declarar mal una licencia es peor que dejarla
|
|
vacía — convierte un hueco visible en una afirmación falsa. Concretamente se descartó el atajo
|
|
«`k*` = KDE ⇒ LGPL»: en este catálogo `kail`, `kind`, `ko`, `kopia`, `krew`, `kustomize`, `kyverno`
|
|
y toda la familia `kube*` son herramientas Go sin relación con KDE.
|
|
|
|
### El texto de la licencia dentro del paquete — ✅ HECHO (y no donde yo dije)
|
|
> **CORRECCIÓN.** Esto decía «va en `hammer pack`». El razonamiento del coste era correcto —las
|
|
> fases SÍ entran al hash, así que hacerlo en la receta re-hashearía las 1141— pero **el sitio
|
|
> estaba mal**: `pack` produce un `.swm`, una receta de transformación sobre fuente pública que por
|
|
> diseño «NUNCA transporta binarios cocidos», e `install` REPRODUCE construyendo. **El canal de
|
|
> paquetes de hammer no distribuye binarios.** Donde sí se entrega un binario es en la **imagen
|
|
> instalable**, y ahí se hace ahora: `scripts/licencias-rootfs.sh` escribe
|
|
> `/usr/share/licenses/<pkg>/` con el texto canónico de cada licencia de la expresión, más un
|
|
> `MANIFEST.tsv` (1,0 MB para el perfil `cli`). Los 44 textos SPDX viven en `licenses/`.
|
|
>
|
|
> **Y VETA**: sale ≠0 si un paquete del rootfs no declara licencia. Al estrenarlo reveló que `base`
|
|
> y `cli` llevaban 10 y 12 paquetes con binarios y licencia desconocida; hoy van 2 cada uno (`lsof`
|
|
> y `tzdata`, que necesitan la vía `LicenseRef-` y siguen vetando a propósito).
|
|
|
|
### Espejo de fuentes — la obligación que más se malentiende
|
|
La GPL no pide «que el código exista en internet»: pide que **quien recibe el binario pueda obtener
|
|
de nosotros la fuente correspondiente**. Hoy las recetas apuntan a URLs de terceros que se caen.
|
|
|
|
Acá estamos inusualmente bien parados: cada receta pinea `tarball` + `sha256`, así que el espejo es
|
|
mecánico **y encima verificable**. Pero tiene que existir **antes de la primera descarga**.
|
|
|
|
### Marcas
|
|
Redistribuir Firefox con su nombre y logo exige cumplir la política de marca de Mozilla (por eso
|
|
Debian tuvo Iceweasel). Decidir por adelantado: cumplir o rebrandear. **No bloquea el primer
|
|
lanzamiento** si se sale sin navegador propio.
|
|
|
|
### La licencia de hammer — ✅ ya está
|
|
`LICENSE` en la raíz y `license = "MIT"` en `Cargo.toml`. *(El SDD 19 decía que faltaba; era falso.)*
|
|
|
|
## I.3 Infraestructura pública
|
|
|
|
1. **Espejo de paquetes e imágenes.** Dimensionado real: el store son 128 G, pero **~60% es información de depuración** ⇒ separando `-debug` en paquetes aparte el espejo baja a **~51 G** (medido en la etapa 3 del SDD 23; el «79%» que se citaba era sobre el CONTENIDO BINARIO, no sobre el tamaño de artefacto).
|
|
2. **Cadena de firma de release.** Hoy hay firma de índice. Falta el nivel de arriba: **clave raíz
|
|
fuera de línea**, claves de firma rotables y un procedimiento escrito para cuando se filtre una.
|
|
Firma sin gestión de claves es teatro.
|
|
3. **Evidencia de reproducibilidad publicada.** Es *el* diferenciador: publicar junto a cada imagen
|
|
los `ArtifactHash` de toda su clausura, para que un tercero reconstruya y compare. Es lo que
|
|
convierte «somos reproducibles» en un hecho comprobable por un extraño.
|
|
4. **Respuesta a seguridad**: un canal para reportes y —lo importante— la capacidad **demostrada** de
|
|
empujar una actualización y que llegue. Ensayar el ciclo completo con un CVE de mentira.
|
|
|
|
## I.4 Que se pueda instalar y usar
|
|
|
|
1. **Imagen instalable validada en METAL**, no sólo en QEMU. Está a medio camino: el USB de KDE en
|
|
metal está **en curso** y falta re-quemarlo. Reglas ya pagadas caro: validar imágenes de
|
|
escritorio **con pantalla**, nunca sólo `-nographic`; `/dev/console` es el serial, así que cada
|
|
capa debe escribir a `/dev/tty0`; y **nunca quemar a un NVMe**.
|
|
2. **Matriz de hardware honesta**: en qué se probó y en qué no. Vale más «probado en estas 3
|
|
máquinas» que «debería funcionar».
|
|
3. **Actualización en sitio probada de verdad**: instalar N, actualizar a N+1, y que arranque. Y
|
|
**rollback**, que con un store direccionado por contenido debería ser barato — es la ventaja
|
|
natural de esta arquitectura y conviene que sea función de primera clase.
|
|
4. **Documentación mínima**: instalar, gestionar paquetes, reportar un fallo.
|
|
5. **Sitio de descarga** con sumas y firmas, y las instrucciones para verificarlas.
|
|
|
|
## I.5 Lo que falta de sistema para que no se note pobre
|
|
|
|
Presente ya: `networkmanager`, `pipewire`, `wireplumber`, `polkit`, `seatd`, `upower`, `tzdata`,
|
|
`fontconfig`. **Falta**: `cups` (impresión), `bluez` (bluetooth), y tipografías/locales revisados.
|
|
|
|
---
|
|
|
|
# PARTE II — De PUBLICABLE a «la distro está COMPLETA»
|
|
|
|
Acá está el trabajo grande, y conviene decir los tamaños en voz alta.
|
|
|
|
## II.1 WMs Wayland ligeros — ✅ HECHO EN UNA NOCHE (2026-08-07/08)
|
|
> **Actualizado.** Esta sección decía «medido: no hay ninguno — de toda la familia sólo existen
|
|
> `foot` y `mako`». Ya no. La hipótesis que traía —«son baratos comparados con los escritorios
|
|
> completos: no hay una torre de C debajo»— **se cumplió y ahora está medida**: KDE y GNOME fueron
|
|
> campañas de semanas; esto salió en una noche.
|
|
|
|
**10 recetas selladas** en la cola `recipes/incoming-wlr/`, 12 binarios:
|
|
|
|
| pieza | qué aporta |
|
|
|---|---|
|
|
| `wlroots` 0.18.2 | la biblioteca de la que cuelga todo lo demás |
|
|
| `sway` 1.10 | el compositor (+ swaybar, swaymsg, swaynag) |
|
|
| `yambar` | la barra de estado |
|
|
| `fuzzel` | el lanzador de aplicaciones |
|
|
| `swaybg` · `swaylock` · `swayidle` | fondo, bloqueo (con PAM) e inactividad |
|
|
| `grim` · `slurp` | captura de pantalla y selección de región |
|
|
| `wl-clipboard` | `wl-copy` / `wl-paste` |
|
|
|
|
Con `foot` (ya en el corpus) como terminal, el perfil **`escritorio-sway` cierra 121/121** y
|
|
**arranca en QEMU**: ver `docs/evidencia/sway-qemu-2026-08-08.png`.
|
|
|
|
**`waybar` queda fuera POR MEDICIÓN**, no por gusto: pide `gtkmm-3.0` —GTK**3** *y* sus bindings de
|
|
C++— más gtk-layer-shell, jsoncpp, fmt, spdlog, sigc++, date y libnl. Es el muro de GTK3 aparcado
|
|
por diseño, con ocho recetas nuevas encima. `yambar` es C puro, del mismo autor que foot/fcft/fuzzel,
|
|
y sus dependencias ya estaban selladas. Si algún día entra GTK3, waybar vuelve a la mesa.
|
|
|
|
Faltan otros compositores (`labwc`, `river`, `niri`), que ahora son baratos porque wlroots ya está.
|
|
|
|
### ⚠️ LA LECCIÓN QUE VALE PARA TODO ESTE DOCUMENTO: **sellado ≠ arranca**
|
|
El grafo decía **121/121, falta 0** — y entre eso y una pantalla con algo dibujado hubo **seis muros
|
|
y ocho ciclos de imagen**. Ninguno era visible en un grafo de dependencias, porque ninguno es una
|
|
dependencia de build:
|
|
|
|
1. **`PATH` vacío** — el `console-getty` no lo exporta; ni `mkdir` se encontraba.
|
|
2. **`libz.so.1` ausente del rootfs** — el `zlib` del corpus es sólo estático y la compartida vive
|
|
en otra cola. Se cazó comparando los `NEEDED` del ELF contra el rootfs.
|
|
3. **`LIBSEAT_BACKEND=builtin` no existe en NUESTRO libseat** — la receta lo construye con un solo
|
|
backend. *La receta manda sobre lo que uno cree recordar del proyecto.*
|
|
4. **`/run` de sólo lectura** — la raíz es inmutable por diseño; el error («check permissions»)
|
|
sonaba a permisos y era un filesystem read-only.
|
|
5. **`xkeyboard-config` ausente** — sin los datos XKB, xkbcommon aborta.
|
|
6. **Sin tipografías no hay terminal** — `fcft: failed to load primary fonts`.
|
|
|
|
Y el método: **el veredicto es contar colores del PPM, no leer el log.** Hubo un arranque con TODO
|
|
verde —salida activada, modo correcto, «Commit of 1 outputs succeeded», workspace creado— y la
|
|
captura **100% negra**. Un compositor puede estar vivo y no pintar nada.
|
|
|
|
⇒ **Corolario para §4.1 y para cualquier estimación de este documento**: que un perfil cierre en el
|
|
grafo prueba que la imagen SE ARMA, no que ARRANQUE. Los otros perfiles no validados en metal
|
|
cargan esa misma distancia, y conviene no prometer fechas contra el número del grafo.
|
|
|
|
## II.2 Aplicaciones gráficas de terceros — **medido: cero**
|
|
No hay ni una. Por coste creciente:
|
|
|
|
- **Barato** (y es lo que hace que la distro se sienta usable): visor de imágenes (`imv`), lector PDF
|
|
(`zathura`), reproductor (`mpv`), gestor de archivos, editor de texto gráfico, emulador de terminal
|
|
adicional (`alacritty`, `kitty`).
|
|
- **Caro**: **LibreOffice**.
|
|
- **El más caro de todo el catálogo**: **un navegador**. Firefox es Rust + C++ + su propio sistema de
|
|
build, y arrastra cbindgen, nasm, nodejs y una cadena de `*-sys` con C++ — que es **justo la
|
|
frontera que el techo MSRV del sandbox (1.96) no cruza todavía**. Presupuestarlo como un frente
|
|
propio, no como «una receta más».
|
|
|
|
## II.3 Deuda técnica de fondo que conviene cerrar antes de crecer
|
|
|
|
- **Las 16 recetas con `compiler = "gcc"`** (contadas parseando TOML; `grep` cuenta comentarios).
|
|
Las 12 de Rust son **un solo problema**: falta el unwinder de libgcc.
|
|
- **No-determinismo en 92 paquetes**, todos por rutas `/src` incrustadas en secciones `.debug_*`. El
|
|
arreglo (`-ffile-prefix-map` global) re-hashea ~720 recetas: decisión de arquitectura, no remiendo.
|
|
- **La carrera del árbol de fuentes (ADR 0012)**, pendiente y **sin decidir**: dos builds de la misma
|
|
dependencia se pisan. Aviso registrado: *un lock sólo en la extracción parece correcto y NO lo es.*
|
|
- **El multi-init**: los inits del catálogo **compiten** con arje-zero, no se apilan.
|
|
|
|
## II.4 Sostenibilidad — lo que decide si sobrevive al primer mes
|
|
Versionado y cadencia escritos; **reconstrucción desde cero en una máquina limpia, cronometrada** —
|
|
la prueba de que el proyecto no depende de un laptop concreto, que es exactamente la preocupación que
|
|
originó el respaldo del 2026-08-07.
|
|
|
|
---
|
|
|
|
# PARTE III — El resumen ejecutivo
|
|
|
|
**Para PUBLICABLE falta, en una línea cada uno:**
|
|
|
|
1. Arreglar el entorno del worker → caen las 12 recetas en deuda.
|
|
2. Terminar las licencias (913) e inyectar el texto en `hammer pack`.
|
|
3. Montar el espejo de fuentes.
|
|
4. Clave raíz fuera de línea y procedimiento de rotación.
|
|
5. Imagen validada en metal (re-quemar el USB).
|
|
6. Actualización N→N+1 probada, con rollback.
|
|
7. Espejo de paquetes (~30 G separando `-debug`), sitio, sumas y firmas.
|
|
8. `cups` y `bluez`.
|
|
9. Documentación mínima y un canal de reportes.
|
|
|
|
**Se puede publicar SIN**: navegador propio, ofimática, y el reconstructor independiente. Son
|
|
objetivos, no requisitos.
|
|
|
|
**Para COMPLETA falta, además**: el juego de aplicaciones gráficas, LibreOffice, el navegador, y
|
|
cerrar la deuda de fondo (gcc, determinismo `.debug_`, ADR 0012).
|
|
*(Los WMs ligeros ya NO están en esta lista: wlroots + sway + accesorios se cerraron el 2026-08-07/08
|
|
y el perfil arranca en QEMU — ver §II.1. También faltan otros compositores, pero ahora son baratos.)*
|
|
|
|
---
|
|
|
|
## 7. Lo que este documento NO puede decirte
|
|
|
|
Todos los números de acá salen del grafo, y el grafo tiene un límite que conviene tener presente
|
|
antes de leerlo como un plan: **prueba que una imagen SE ARMA, no que ARRANQUE.**
|
|
|
|
Está medido, no supuesto. El perfil `escritorio-sway` cerró **121/121, falta 0** — y entre eso y una
|
|
pantalla con algo dibujado hubo **seis muros y ocho ciclos de imagen**: PATH vacío, un `.so`
|
|
ausente del rootfs, un backend de libseat que nuestra receta no construye, `/run` de sólo lectura,
|
|
los datos XKB, y la falta de tipografías. Ninguno era una dependencia de build, así que ninguno podía
|
|
aparecer en el grafo.
|
|
|
|
⇒ Cuando este documento diga que algo «cierra», leelo como *se puede intentar*, no como *funciona*.
|
|
La distancia se paga una vez por perfil y se paga entera. Los tres escritorios que aún no se
|
|
validaron con pantalla la deben.
|
|
|
|
---
|
|
|
|
## 8. Por qué `escritorio-kde` está en 76/162 — diagnóstico (2026-08-08)
|
|
|
|
**No es daño de la campaña del split**, y tampoco es un fallo de `store-gc`. Es más simple y más
|
|
incómodo: **esos artefactos no existen en ninguna parte**.
|
|
|
|
### Lo que se midió, en orden
|
|
1. **86 nodos del perfil sin artefacto en su hash vigente.**
|
|
2. **No lo causó el split**: se revirtieron una por una todas las recetas tocadas hoy —las 3
|
|
bibliotecas base, las 30 hojas, `dbus`, las 38 de la 2ª tanda— y el número **no se movió**.
|
|
3. **La FRONTERA de la deriva son 7 recetas** (las únicas cuyas deps sí están al día):
|
|
`dbus`, `libnl`, `libpcap`, `libxkbcommon`, `lm-sensors`, `perl-xml-parser`, `vulkan-loader`.
|
|
Las otras 79 cuelgan de ellas.
|
|
4. **Las 7 son SOMBRAS de `incoming-kde`**, no las canónicas. Las del corpus están perfectamente al
|
|
día — por eso el problema es invisible desde el grafo del corpus.
|
|
5. **No fue `store-gc`**: sus hashes vigentes no figuran en ningún manifiesto de borrado, y tres de
|
|
ellas (`libpcap`, `lm-sensors`, `vulkan-loader`) nunca se podaron.
|
|
6. **Ni el hub ni el worker los tienen.** No están «en otro sitio»: no están.
|
|
|
|
### La causa de fondo, y por qué importa más que KDE
|
|
La cola KDE se construyó en workers EFÍMEROS. El sync del store es **unidireccional** (worker→hub) y
|
|
esos workers ya no existen. Cuando algo del sustrato compartido cambió después de aquella campaña,
|
|
las sombras de KDE se re-hashearon y **nadie las reconstruyó**, porque el hub nunca fue la máquina
|
|
donde vivía ese escritorio.
|
|
|
|
⇒ **Con flota efímera y sync unidireccional, un escritorio puede dejar de ser reconstruible-desde-el-
|
|
store sin que ningún indicador lo diga.** El grafo seguía reportando 162/162 en un JSON generado
|
|
semanas antes, y sólo se vio al regenerarlo.
|
|
|
|
### Qué cuesta arreglarlo
|
|
**86 reconstrucciones en la granja**, empezando por las 7 de la frontera. No hay muro técnico
|
|
conocido: son recetas que ya construyeron alguna vez. Es tiempo de cómputo, no investigación.
|