takana/docs/27-perfiles-instalables-y-el-instalador.md

SDD 27 — Metapaquetes instalables: del rootfs hidratado al takana install escritorio-kde

Estado: PROPUESTA. Nada de lo de acá está implementado. Lo que sí está medido es el punto de partida, y las mediciones llevan fecha 2026-09-09. Escrito a pedido del usuario mientras se cerraban los huecos de la imagen KDE.

0. La pregunta

Hoy sabemos construir. Sabemos hidratar un rootfs y meterlo en una imagen que arranca. Lo que no existe es instalar un escritorio como una unidad: hoy «KDE» es una lista dentro de un fichero del repo, no algo que un usuario pueda pedir.

Y hay una pregunta previa que el usuario formuló mejor de lo que estaba escrito en ningún lado:

el toolbox CLI es general, que sea piso userland del sistema siempre. los extras son igual instalaciones, depende de quién instale qué.

Eso son tres capas distintas, y hoy el repo las mezcla en una sola lista por escritorio.

1. Lo medido: hoy los escritorios NO heredan la base

docs/state/targets.toml declara un perfil base de 27 paquetes: bash, git, sudo, doas, util-linux, shadow, kbd, procps-ng, iproute2, iputils, dhcpcd, e2fsprogs, dosfstools, gnupg, ca-certificates… El fichero ya avisa que «kde/gnome/cosmic NO heredan base», pero la consecuencia no estaba escrita. Medida:

De los 27 paquetes de base, la clausura de escritorio-kde alcanza 2.

Y comprobado contra el rootfs real de la imagen KDE (kde-qemu-rootfs):

se busca	está
bash, git, sudo, doas, dhcpcd, useradd, gpg	NO
ip, mount, fsck	sí, pero son applets de busybox (/sbin/ip → ../bin/busybox)
ssh, curl	sí, de rebote: entran por la clausura de KDE, no por base

⇒ Sí: abrís el escritorio y es como si base no existiera. No hay shell de verdad (busybox sh, no bash), no hay sudo ni doas, no hay git, y no hay dhcpcd — o sea que la imagen no sabe pedir una IP salvo lo que haga busybox. Lo que sí hay es el otro base: arje-zero como PID1 más busybox, que es lo mínimo para arrancar. Son dos cosas distintas con el mismo nombre coloquial:

• base de arranque (metal-rootfs): arje-zero + busybox + kernel. La imagen la funde por hardlinks. Existe.
• base de userland ([perfil.base]): las 27. No la funde nadie.

Esto no es un bug de una imagen: es que la composición entre perfiles no está definida.

2. Las tres capas que hay que separar

capa	qué es	quién decide	hoy
piso	userland siempre presente: shell, red, usuarios, paquetes, git	la distro	existe como [perfil.base], no lo hereda nadie
escritorio	KDE / GNOME / COSMIC / sway y lo que los hace ser ellos	la distro	existe como perfil, es lo único que se materializa
extras	lo que cada quien instala encima	el usuario	no existe como operación

Y hay una cuarta que el usuario nombró y conviene no perder: el toolbox CLI. Hoy hay 652 recetas selladas que ninguna imagen alcanza — 361 Go, 214 Rust, 67 C — y son casi todas herramientas de línea de comandos. Ya construidas, ya reproducibles: coste de build cero, sólo declararlas. Si el toolbox es piso, va en la capa 1 y no en cada escritorio.

3. Un «metapaquete» ya existe, y se llama perfil

[perfil.escritorio-kde] con sus 49 raíces es el metapaquete: una lista de nombres cuya clausura define qué entra. Lo que le falta para ser instalable son tres cosas concretas:

1. Herencia. Un perfil tiene que poder decir hereda = ["base"] en vez de repetir la lista. Hoy los cuatro escritorios repiten dejavu-fonts, desktop-file-utils y las *-shared de runtime, y ya se vio lo que pasa: se añade a uno y se olvida en los otros.
2. Publicación. targets.toml vive en el repo y es de tiempo de build. Para que el instalador lo use tiene que salir al repositorio firmado como un objeto más, igual que un .swm.
3. Un verbo. takana install escritorio-kde no existe: install resuelve un paquete por nombre en el índice. Instalar un perfil es resolver una LISTA y aplicar su clausura.

4. La decisión de fondo del instalador: reproducir o hidratar

Ésta es la única pregunta que no es de implementación, y conviene decidirla antes de escribir código.

Hoy el canal de paquetes NO distribuye binarios. pack produce un .swm —una receta de transformación sobre fuente pública— e install reproduce construyendo, con cache-hit del corpus. Es coherente con todo el diseño: lo que viaja es la receta, no el binario.

• Reproducir un escritorio entero en la máquina del usuario son horas de compilación (KDE son 301 nodos; Qt y Firefox solos ya son la mayor parte de una tarde). Coherente y honesto, pero inaceptable como experiencia de instalación.
• Hidratar desde artefactos firmados es lo que ya hace hydrate-profile.py: segundos, porque son hardlinks contra el store. Pero eso es entregar binarios, y activa entera la obligación de licencias que se cerró el 2026-09-09 (scripts/licencias-rootfs.sh, que veta si un paquete no declara licencia). También activa la pregunta de confianza: el ADR 0014 ya dice que el cuerpo es inmutable y direccionado por contenido, así que el origen no necesita confianza — lo que se firma es la raíz, no el servidor.

La salida no es elegir una: es que las dos existan y el usuario elija, igual que el ADR 0014 hizo con los orígenes. Instalar por hidratación es el camino normal; reproducir es el camino auditable, y que exista es lo que hace verificable al primero. Lo que hay que definir es el default — y ahí la respuesta razonable es hidratar, porque el que quiere auditar puede reproducir cuando quiera y comparar hashes, que es exactamente lo que selfhost-verify ya hace.

5. La imagen y el instalador son el mismo problema con dos salidas

Hoy hay dos caminos que hacen casi lo mismo y no se hablan:

• Imagen: perfil → hydrate-profile.py → rootfs → install-image-efi.sh → .img que arranca.
• Instalador: TUI + base-system, que instala sobre un disco.

Si un perfil es publicable e instalable, los dos son el mismo verbo con distinto destino: uno escribe a una imagen, el otro a una partición. Vale la pena unificarlos antes de que diverjan más: hoy ya divergieron una vez —los hydrate-*.sh por escritorio contra targets.toml, con 21 paquetes declarados que no llegaban a la imagen de GNOME y 17 a la de COSMIC— y costó encontrarlo.

6. Sobre el nombre del paquete (.swm vs .tkn)

.swm no es residuo del renombre: significa «Software Mutación» y describe lo que el fichero es —una mutación reproducible sobre una fuente—, no la marca. Renombrarlo a .tkn sería alinear marca y formato, y es defendible, pero no lo pide ninguna inconsistencia técnica. Si se hace, es una decisión de ADR y con la misma disciplina que el renombre de hoy: hay que mirar si la extensión entra en algún hash o en el índice del repo antes de tocarla.

El verbo, en cambio, ya es el correcto: takana install.

7. Orden propuesto

1. Herencia entre perfiles — HECHO el 2026-09-09, y resultó ser una línea por perfil: el mecanismo hereda YA EXISTÍA en scripts/targets.py (transitivo, con detección de ciclos y orden preservado) y escritorio-sway ya lo usaba desde el 2026-08-07. Los otros tres simplemente no lo habían declarado. Ahora kde/gnome/cosmic heredan cli, que hereda base. Medido: raíces 49→96 (kde), 39→86 (gnome), 43→88 (cosmic); nodos 301→356, 204→256, 162→216; deuda 0 en los tres —no hubo que construir nada, ya estaba todo sellado— y cero colisiones nuevas al hidratar (los 28 .hammer-tmp son los mismos de gmp/mpfr de antes). Verificado en el rootfs: aparecen bash, sudo, doas, git, dhcpcd, useradd, gpg, rg, fd, bat, y /sbin/ip deja de ser el applet de busybox para ser el binario de iproute2. ⚠ escritorio-mirada NO hereda a propósito: es el rootfs slim del USB y sumarle 47 raíces contradice su razón de ser. Si algún día se quiere, es la misma línea.
2. Decidir el piso: qué del toolbox CLI de 652 entra en base. Coste de build cero.
3. Publicar perfiles al repositorio firmado.
4. takana install <perfil>, hidratando por defecto y con --reproduce como camino auditable.
5. Unificar imagen e instalador sobre ese verbo.

Los pasos 1 y 2 se pueden hacer ya y no dependen de ninguna decisión de arquitectura.

8. «Metapaquete», no «perfil» — y el problema real que destapa el nombre

El usuario lo dijo mejor: «perfil» suena a preset exclusivo, y eso arrastra una suposición que nadie decidió. La pregunta que lo destapa es concreta:

¿no voy a poder instalar KDE y mirada y GNOME al mismo tiempo, y cambiar entre ellas con un greeter?

En el STORE ya conviven, y no en teoría. Medido el 2026-09-09 comparando los dos rootfs hidratados que hay en disco (kde-rootfs 78.934 ficheros, gnome-rootfs 19.955):

rutas presentes en LOS DOS	14.455
…de ésas, mismo inodo (el MISMO artefacto del store)	12.766 (88 %)
…inodo distinto = colisión real	1.689 (12 %)

O sea que el 88 % de lo compartido no es un conflicto: es literalmente el mismo fichero, porque el store es direccionado por contenido y los dos escritorios lo enlazan. Lo que impide instalar dos escritorios no es el store: es PROYECTARLOS AL MISMO /usr. 1.689 ficheros quieren la misma ruta con contenido distinto y gana el último que se proyecte — el mismo cuadro que targets.toml ya documenta para las dos poppler y que se vio hoy con gmp/mpfr dejando 28 .hammer-tmp.

Y las colisiones no son misteriosas: libuuid.so.1.3.0, dbus-daemon, gdbus, gapplication, /etc/dbus-1/*.conf… Salen de que cada cola tiene su propia glib y su propio dbus. Son recetas distintas con el mismo soname.

⇒ Hay dos caminos, y no son excluyentes:

1. Bajar las colisiones: unificar lo que no tiene por qué estar duplicado (una sola glib, un solo dbus). Ataca la causa y además hace más chicas las imágenes. Es trabajo de catálogo.
2. No proyectar a un /usr único, que es lo que el SDD 18 ya propone: «activar un nodo = montar su composefs como /usr». Con eso cada escritorio es una VISTA compuesta y las 1.689 colisiones dejan de existir por construcción — no hay un /usr compartido que aplastar.

El greeter encaja solo: el arranque por GRAFO del ADR 0010 ya elige qué clausura activar, y mirada-greeter existe. Elegir escritorio en el greeter = elegir qué vista montar.

Corolario para el nombre: si un escritorio es una vista montable y no un preset del sistema, entonces metapaquete es la palabra correcta y perfil la equivocada — instalás tres y elegís al arrancar, igual que en cualquier distro. Renombrar la clave de targets.toml es barato en concepto y caro en llamadores (build-state, drenar, hydrate-profile, vigia-imagen, seed-graph); vale como decisión de ADR, con el mismo cuidado que el renombre de hammer→takana: mirar antes si la palabra entra en algún hash o en el índice del repo.

⚠ Y una consecuencia de orden: el punto 1 del plan (herencia) no cambia por esto, pero el punto 5 sí. Unificar imagen e instalador sobre un /usr proyectado es construir sobre el supuesto de que sólo hay un escritorio a la vez. Antes de unificarlos conviene decidir si el destino es un FHS plano o una vista composefs, porque es la diferencia entre «instalás uno» y «instalás los tres».

9. Herencia hace DOS trabajos distintos, y sólo uno es herencia

La herencia del §7.1 contesta «¿qué contiene este metapaquete?». El usuario preguntó otra cosa:

¿voy a poder ejecutar un kate desde mirada, o kate está para KDE y no se hereda?

Eso es «¿qué puede correr en este sistema?», y hoy se confunde con lo anterior porque hay un solo mecanismo.

kate no es «de KDE» técnicamente — lo es sólo por empaquetado

Medido el 2026-09-09 sobre la clausura de recipes/incoming-kde/kate.toml:

• 110 recetas en total.
• Lo único que suena a Plasma son kwindowsystem, plasma-activities y plasma-wayland-protocols — y las tres son librerías, no el shell. La última es literalmente XML de protocolo.
• No aparece plasmashell, ni kwin, ni plasma-workspace.

⇒ kate necesita Qt6 + KF6 + un compositor Wayland. Mirada tiene compositor. Que hoy no se pueda ejecutar desde mirada no es una limitación técnica: es que no está instalado.

Coste medido de tenerlo ahí: la clausura de escritorio-mirada son 41 nodos, la de kate 110, y 24 ya están ⇒ habría que sumar 86, que es esencialmente traerse Qt6 y KF6. Y ese precio es el mismo desde mirada que desde sway: no lo cobra KDE, lo cobra Qt.

Las tres clases, y sólo la primera es herencia

clase	qué es	¿se hereda?
piso	base + cli	sí — todo sistema lo tiene (hecho en §7.1)
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
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

La prueba de que la distinción ya existe sin estar nombrada

mpv, atuq, swayimg y libnotify están declaradas en los CUATRO escritorios — repetidas, no heredadas. zathura en tres, foot en dos. O sea que el repo ya trata las apps distinto de kwin, sólo que copiando la línea en cada perfil en vez de decirlo.

Y el mecanismo también existe a medias: esas cuatro viven en el CORPUS y no en una cola, con el comentario explícito de que es «justamente para poder listarse en las cuatro». Falta el último paso.

Propuesta

Que escritorio-kde sea el escritorio —shell, compositor, tema, ajustes, energía— y que las apps salgan a metapaquetes propios: kate suelto, o agrupadas en algo tipo kde-apps, instalables desde cualquier sistema. Con eso la pregunta del usuario se contesta sola:

takana install kate      # desde mirada, desde sway, desde donde sea

trae sus 86 recetas faltantes y funciona, sin instalar Plasma.

⚠ Y esto se lleva bien con el §8: si un escritorio es una VISTA montable y las apps son metapaquetes aparte, entonces «tengo KDE y GNOME instalados y elijo en el greeter» y «uso kate dentro de mi sesión de GNOME» dejan de ser dos problemas distintos. Son el mismo: qué clausura se compone para esta sesión.

Coste: mueve unas 20 declaraciones de targets.toml y no toca ni una receta ni un artefacto — es reclasificar, no reconstruir. No se hizo todavía porque es decisión de diseño, no de limpieza.