1# SDD 27 — Metapaquetes instalables: del rootfs hidratado al `takana install escritorio-kde`
2
3> **Estado: PROPUESTA.** Nada de lo de acá está implementado. Lo que sí está medido es el punto de
4> partida, y las mediciones llevan fecha 2026-09-09. Escrito a pedido del usuario mientras se
5> cerraban los huecos de la imagen KDE.
6
7## 0. La pregunta
8
9Hoy sabemos construir. Sabemos hidratar un rootfs y meterlo en una imagen que arranca. Lo que no
10existe es **instalar un escritorio como una unidad**: hoy «KDE» es una lista dentro de un fichero
11del repo, no algo que un usuario pueda pedir.
12
13Y hay una pregunta previa que el usuario formuló mejor de lo que estaba escrito en ningún lado:
14
15> *el toolbox CLI es general, que sea piso userland del sistema siempre. los extras son igual
16> instalaciones, depende de quién instale qué.*
17
18Eso son **tres capas distintas**, y hoy el repo las mezcla en una sola lista por escritorio.
19
20## 1. Lo medido: hoy los escritorios NO heredan la base
21
22`docs/state/targets.toml` declara un perfil `base` de **27 paquetes**: `bash`, `git`, `sudo`, `doas`,
23`util-linux`, `shadow`, `kbd`, `procps-ng`, `iproute2`, `iputils`, `dhcpcd`, `e2fsprogs`,
24`dosfstools`, `gnupg`, `ca-certificates`… El fichero ya avisa que «kde/gnome/cosmic **NO** heredan
25base», pero la consecuencia no estaba escrita. Medida:
26
27> **De los 27 paquetes de `base`, la clausura de `escritorio-kde` alcanza 2.**
28
29Y comprobado contra el rootfs real de la imagen KDE (`kde-qemu-rootfs`):
30
31| se busca | está |
32|---|---|
33| `bash`, `git`, `sudo`, `doas`, `dhcpcd`, `useradd`, `gpg` | **NO** |
34| `ip`, `mount`, `fsck` | sí, pero **son applets de busybox** (`/sbin/ip → ../bin/busybox`) |
35| `ssh`, `curl` | sí, de rebote: entran por la clausura de KDE, no por `base` |
36
37⇒ **Sí: abrís el escritorio y es como si `base` no existiera.** No hay shell de verdad (busybox `sh`,
38no bash), no hay `sudo` ni `doas`, no hay `git`, y **no hay `dhcpcd`** — o sea que la imagen no sabe
39pedir una IP salvo lo que haga busybox. Lo que sí hay es el **otro** base: `arje-zero` como PID1 más
40busybox, que es lo mínimo para arrancar. Son dos cosas distintas con el mismo nombre coloquial:
41
42- **base de arranque** (`metal-rootfs`): arje-zero + busybox + kernel. La imagen la funde por
43  hardlinks. Existe.
44- **base de userland** (`[perfil.base]`): las 27. **No la funde nadie.**
45
46Esto no es un bug de una imagen: es que la composición entre perfiles **no está definida**.
47
48## 2. Las tres capas que hay que separar
49
50| capa | qué es | quién decide | hoy |
51|---|---|---|---|
52| **piso** | userland siempre presente: shell, red, usuarios, paquetes, `git` | la distro | existe como `[perfil.base]`, no lo hereda nadie |
53| **escritorio** | KDE / GNOME / COSMIC / sway y lo que los hace ser ellos | la distro | existe como perfil, es lo único que se materializa |
54| **extras** | lo que cada quien instala encima | el usuario | no existe como operación |
55
56Y hay una cuarta que el usuario nombró y conviene no perder: **el toolbox CLI**. Hoy hay
57**652 recetas selladas que ninguna imagen alcanza** — 361 Go, 214 Rust, 67 C — y son casi todas
58herramientas de línea de comandos. Ya construidas, ya reproducibles: **coste de build cero, sólo
59declararlas**. Si el toolbox es piso, va en la capa 1 y no en cada escritorio.
60
61## 3. Un «metapaquete» ya existe, y se llama perfil
62
63`[perfil.escritorio-kde]` con sus 49 raíces **es** el metapaquete: una lista de nombres cuya
64clausura define qué entra. Lo que le falta para ser instalable son tres cosas concretas:
65
661. **Herencia.** Un perfil tiene que poder decir `hereda = ["base"]` en vez de repetir la lista. Hoy
67   los cuatro escritorios repiten `dejavu-fonts`, `desktop-file-utils` y las `*-shared` de runtime,
68   y ya se vio lo que pasa: se añade a uno y se olvida en los otros.
692. **Publicación.** `targets.toml` vive en el repo y es de tiempo de build. Para que el instalador
70   lo use tiene que salir al repositorio firmado como un objeto más, igual que un `.swm`.
713. **Un verbo.** `takana install escritorio-kde` no existe: `install` resuelve **un paquete** por
72   nombre en el índice. Instalar un perfil es resolver una LISTA y aplicar su clausura.
73
74## 4. La decisión de fondo del instalador: reproducir o hidratar
75
76Ésta es la única pregunta que no es de implementación, y conviene decidirla antes de escribir código.
77
78**Hoy el canal de paquetes NO distribuye binarios.** `pack` produce un `.swm` —una receta de
79transformación sobre fuente pública— e `install` **reproduce construyendo**, con cache-hit del
80corpus. Es coherente con todo el diseño: lo que viaja es la receta, no el binario.
81
82- **Reproducir** un escritorio entero en la máquina del usuario son **horas** de compilación (KDE son
83  301 nodos; Qt y Firefox solos ya son la mayor parte de una tarde). Coherente y honesto, pero
84  inaceptable como experiencia de instalación.
85- **Hidratar desde artefactos firmados** es lo que ya hace `hydrate-profile.py`: segundos, porque
86  son hardlinks contra el store. Pero eso **es entregar binarios**, y activa entera la obligación de
87  licencias que se cerró el 2026-09-09 (`scripts/licencias-rootfs.sh`, que veta si un paquete no
88  declara licencia). También activa la pregunta de confianza: el ADR 0014 ya dice que el cuerpo es
89  inmutable y direccionado por contenido, así que **el origen no necesita confianza** — lo que se
90  firma es la raíz, no el servidor.
91
92**La salida no es elegir una: es que las dos existan y el usuario elija**, igual que el ADR 0014 hizo
93con los orígenes. Instalar por hidratación es el camino normal; reproducir es el camino auditable, y
94que exista es lo que hace verificable al primero. Lo que hay que definir es el **default** — y ahí la
95respuesta razonable es hidratar, porque el que quiere auditar puede reproducir cuando quiera y
96comparar hashes, que es exactamente lo que `selfhost-verify` ya hace.
97
98## 5. La imagen y el instalador son el mismo problema con dos salidas
99
100Hoy hay dos caminos que hacen casi lo mismo y no se hablan:
101
102- **Imagen**: perfil → `hydrate-profile.py` → rootfs → `install-image-efi.sh` → `.img` que arranca.
103- **Instalador**: TUI + `base-system`, que instala sobre un disco.
104
105Si un perfil es publicable e instalable, los dos son **el mismo verbo con distinto destino**: uno
106escribe a una imagen, el otro a una partición. Vale la pena unificarlos antes de que diverjan más:
107hoy ya divergieron una vez —los `hydrate-*.sh` por escritorio contra `targets.toml`, con 21 paquetes
108declarados que no llegaban a la imagen de GNOME y 17 a la de COSMIC— y costó encontrarlo.
109
110## 6. Sobre el nombre del paquete (`.swm` vs `.tkn`)
111
112`.swm` **no es residuo del renombre**: significa «Software Mutación» y describe lo que el fichero
113es —una mutación reproducible sobre una fuente—, no la marca. Renombrarlo a `.tkn` sería alinear
114marca y formato, y es defendible, pero **no lo pide ninguna inconsistencia técnica**. Si se hace,
115es una decisión de ADR y con la misma disciplina que el renombre de hoy: hay que mirar si la
116extensión entra en algún hash o en el índice del repo antes de tocarla.
117
118El verbo, en cambio, ya es el correcto: **`takana install`**.
119
120## 7. Orden propuesto
121
1221. ~~**Herencia entre perfiles**~~ — **HECHO el 2026-09-09**, y resultó ser una línea por perfil:
123   el mecanismo `hereda` YA EXISTÍA en `scripts/targets.py` (transitivo, con detección de ciclos y
124   orden preservado) y `escritorio-sway` ya lo usaba desde el 2026-08-07. Los otros tres
125   simplemente no lo habían declarado. Ahora kde/gnome/cosmic heredan `cli`, que hereda `base`.
126   Medido: raíces 49→96 (kde), 39→86 (gnome), 43→88 (cosmic); nodos 301→356, 204→256, 162→216;
127   **deuda 0 en los tres** —no hubo que construir nada, ya estaba todo sellado— y **cero colisiones
128   nuevas** al hidratar (los 28 `.hammer-tmp` son los mismos de `gmp`/`mpfr` de antes).
129   Verificado en el rootfs: aparecen `bash`, `sudo`, `doas`, `git`, `dhcpcd`, `useradd`, `gpg`,
130   `rg`, `fd`, `bat`, y `/sbin/ip` deja de ser el applet de busybox para ser el binario de iproute2.
131   ⚠ `escritorio-mirada` NO hereda a propósito: es el rootfs *slim* del USB y sumarle 47 raíces
132   contradice su razón de ser. Si algún día se quiere, es la misma línea.
1332. **Decidir el piso**: qué del toolbox CLI de 652 entra en `base`. Coste de build cero.
1343. **Publicar perfiles** al repositorio firmado.
1354. **`takana install <perfil>`**, hidratando por defecto y con `--reproduce` como camino auditable.
1365. **Unificar imagen e instalador** sobre ese verbo.
137
138Los pasos 1 y 2 se pueden hacer ya y no dependen de ninguna decisión de arquitectura.
139
140## 8. «Metapaquete», no «perfil» — y el problema real que destapa el nombre
141
142El usuario lo dijo mejor: **«perfil» suena a preset exclusivo**, y eso arrastra una suposición que
143nadie decidió. La pregunta que lo destapa es concreta:
144
145> *¿no voy a poder instalar KDE y mirada y GNOME al mismo tiempo, y cambiar entre ellas con un
146> greeter?*
147
148**En el STORE ya conviven, y no en teoría.** Medido el 2026-09-09 comparando los dos rootfs
149hidratados que hay en disco (`kde-rootfs` 78.934 ficheros, `gnome-rootfs` 19.955):
150
151| | |
152|---|---|
153| rutas presentes en LOS DOS | 14.455 |
154| …de ésas, **mismo inodo** (el MISMO artefacto del store) | **12.766** (88 %) |
155| …**inodo distinto** = colisión real | **1.689** (12 %) |
156
157O sea que el 88 % de lo compartido no es un conflicto: es literalmente el mismo fichero, porque el
158store es direccionado por contenido y los dos escritorios lo enlazan. **Lo que impide instalar dos
159escritorios no es el store: es PROYECTARLOS AL MISMO `/usr`.** 1.689 ficheros quieren la misma ruta
160con contenido distinto y gana el último que se proyecte — el mismo cuadro que `targets.toml` ya
161documenta para las dos poppler y que se vio hoy con `gmp`/`mpfr` dejando 28 `.hammer-tmp`.
162
163Y las colisiones no son misteriosas: `libuuid.so.1.3.0`, `dbus-daemon`, `gdbus`, `gapplication`,
164`/etc/dbus-1/*.conf`… Salen de que **cada cola tiene su propia `glib` y su propio `dbus`**. Son
165recetas distintas con el mismo soname.
166
167⇒ Hay **dos caminos**, y no son excluyentes:
168
1691. **Bajar las colisiones**: unificar lo que no tiene por qué estar duplicado (una sola `glib`, un
170   solo `dbus`). Ataca la causa y además hace más chicas las imágenes. Es trabajo de catálogo.
1712. **No proyectar a un `/usr` único**, que es lo que el [SDD 18](18-wawafs-store-vivo.md) ya
172   propone: *«activar un nodo = montar su composefs como `/usr`»*. Con eso cada escritorio es una
173   VISTA compuesta y las 1.689 colisiones dejan de existir por construcción — no hay un `/usr`
174   compartido que aplastar.
175
176El greeter encaja solo: el arranque por GRAFO del ADR 0010 ya elige qué clausura activar, y
177`mirada-greeter` existe. Elegir escritorio en el greeter = elegir qué vista montar.
178
179**Corolario para el nombre**: si un escritorio es una vista montable y no un preset del sistema,
180entonces `metapaquete` es la palabra correcta y `perfil` la equivocada — instalás tres y elegís al
181arrancar, igual que en cualquier distro. Renombrar la clave de `targets.toml` es barato en concepto
182y caro en llamadores (build-state, drenar, hydrate-profile, vigia-imagen, seed-graph); vale como
183decisión de ADR, con el mismo cuidado que el renombre de `hammer`→`takana`: mirar antes si la
184palabra entra en algún hash o en el índice del repo.
185
186⚠ Y una consecuencia de orden: **el punto 1 del plan (herencia) no cambia por esto, pero el punto 5
187sí**. Unificar imagen e instalador sobre un `/usr` proyectado es construir sobre el supuesto de que
188sólo hay un escritorio a la vez. Antes de unificarlos conviene decidir si el destino es un FHS
189plano o una vista composefs, porque es la diferencia entre «instalás uno» y «instalás los tres».
190
191## 9. Herencia hace DOS trabajos distintos, y sólo uno es herencia
192
193La herencia del §7.1 contesta *«¿qué **contiene** este metapaquete?»*. El usuario preguntó otra cosa:
194
195> *¿voy a poder ejecutar un kate desde mirada, o kate está para KDE y no se hereda?*
196
197Eso es *«¿qué **puede correr** en este sistema?»*, y hoy se confunde con lo anterior porque hay un
198solo mecanismo.
199
200### `kate` no es «de KDE» técnicamente — lo es sólo por empaquetado
201
202Medido el 2026-09-09 sobre la clausura de `recipes/incoming-kde/kate.toml`:
203
204- **110 recetas** en total.
205- Lo único que suena a Plasma son `kwindowsystem`, `plasma-activities` y
206  `plasma-wayland-protocols` — y **las tres son librerías**, no el shell. La última es literalmente
207  XML de protocolo.
208- **No aparece `plasmashell`, ni `kwin`, ni `plasma-workspace`.**
209
210⇒ kate necesita Qt6 + KF6 + un compositor Wayland. Mirada **tiene** compositor. Que hoy no se pueda
211ejecutar desde mirada no es una limitación técnica: **es que no está instalado**.
212
213Coste medido de tenerlo ahí: la clausura de `escritorio-mirada` son 41 nodos, la de kate 110, y
214**24 ya están** ⇒ habría que sumar **86**, que es esencialmente traerse Qt6 y KF6. Y ese precio es
215el mismo desde mirada que desde sway: no lo cobra KDE, lo cobra Qt.
216
217### Las tres clases, y sólo la primera es herencia
218
219| clase | qué es | ¿se hereda? |
220|---|---|---|
221| **piso** | `base` + `cli` | **sí** — todo sistema lo tiene (hecho en §7.1) |
222| **escritorio** | `plasmashell`, `kwin`, `breeze`, `powerdevil`, `kscreen` | **no, y no tiene sentido**: son la implementación de *ser* KDE. Correr `kwin` desde mirada no significa nada, mirada ya tiene compositor |
223| **aplicaciones** | `kate`, `okular`, `dolphin`, `gwenview`, `ark`, `spectacle`… | **no se heredan: se INSTALAN**. Hoy están dentro del metapaquete del escritorio, y ahí está el error de clasificación |
224
225### La prueba de que la distinción ya existe sin estar nombrada
226
227`mpv`, `atuq`, `swayimg` y `libnotify` **están declaradas en los CUATRO escritorios** — repetidas,
228no heredadas. `zathura` en tres, `foot` en dos. O sea que el repo **ya trata las apps distinto de
229`kwin`**, sólo que copiando la línea en cada perfil en vez de decirlo.
230
231Y el mecanismo también existe a medias: esas cuatro viven en el CORPUS y no en una cola, con el
232comentario explícito de que es «justamente para poder listarse en las cuatro». Falta el último paso.
233
234### Propuesta
235
236Que `escritorio-kde` sea **el escritorio** —shell, compositor, tema, ajustes, energía— y que las
237apps salgan a metapaquetes propios: `kate` suelto, o agrupadas en algo tipo `kde-apps`, instalables
238desde cualquier sistema. Con eso la pregunta del usuario se contesta sola:
239
240    takana install kate      # desde mirada, desde sway, desde donde sea
241
242trae sus 86 recetas faltantes y funciona, **sin instalar Plasma**.
243
244⚠ Y esto se lleva bien con el §8: si un escritorio es una VISTA montable y las apps son
245metapaquetes aparte, entonces «tengo KDE y GNOME instalados y elijo en el greeter» y «uso kate
246dentro de mi sesión de GNOME» dejan de ser dos problemas distintos. Son el mismo: qué clausura se
247compone para esta sesión.
248
249**Coste**: mueve unas 20 declaraciones de `targets.toml` y no toca ni una receta ni un artefacto —
250es reclasificar, no reconstruir. No se hizo todavía porque es decisión de diseño, no de limpieza.