El usuario preguntó si va a poder ejecutar kate desde mirada o si kate «está para KDE y no se
hereda». La pregunta separa dos cosas que hoy comparten un solo mecanismo: qué CONTIENE un
metapaquete (lo que resolvió el §7.1) y qué PUEDE CORRER en un sistema.
MEDIDO sobre la clausura de kate: son 110 recetas, y lo único que suena a Plasma —kwindowsystem,
plasma-activities, plasma-wayland-protocols— son LIBRERÍAS. No aparece plasmashell, ni kwin, ni
plasma-workspace. O sea que kate necesita Qt6 + KF6 + un compositor, y mirada TIENE compositor: que
hoy no corra ahí no es técnico, es que no está instalado. Coste medido: mirada son 41 nodos, kate
110, ya coinciden 24 ⇒ faltan 86, que es traerse Qt6 y KF6. Ese precio no lo cobra KDE, lo cobra Qt.
Y la distinción YA EXISTE en el repo sin estar nombrada: mpv, atuq, swayimg y libnotify están
declaradas en los CUATRO escritorios —repetidas, no heredadas—, zathura en tres, foot en dos. El
repo ya trata las apps distinto de kwin, sólo que copiando la línea en cada perfil.
Propuesta escrita: que el metapaquete del escritorio sea el ESCRITORIO (shell, compositor, tema,
ajustes) y que las apps salgan a metapaquetes propios instalables desde cualquier sistema, de modo
que `takana install kate` funcione desde mirada sin instalar Plasma. Se lleva bien con el §8: con
vistas montables, «tengo KDE y GNOME y elijo en el greeter» y «uso kate dentro de GNOME» dejan de
ser dos problemas y pasan a ser uno solo — qué clausura se compone para esta sesión.
Cuesta mover ~20 declaraciones de targets.toml y no toca ninguna receta ni ningún artefacto: es
reclasificar, no reconstruir.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
Paso 1 del SDD 27. 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 nunca lo declararon, y eso no era una decisión: era
composición no declarada.
LO QUE ARREGLA, medido antes: de los 27 paquetes del perfil `base`, la clausura de escritorio-kde
alcanzaba DOS. Contra el rootfs real: sin `bash`, sin `sudo`/`doas`, sin `git`, sin `useradd`, sin
`gpg` y **sin `dhcpcd`** —o sea sin con qué pedir una IP—; y lo que parecía estar (`ip`, `mount`,
`fsck`) eran applets de busybox (`/sbin/ip → ../bin/busybox`).
DESPUÉS, verificado hidratando de verdad y no leyendo el grafo: en el rootfs aparecen `bash`,
`sudo`, `doas`, `git`, `dhcpcd`, `useradd`, `gpg`, `rg`, `fd`, `bat`, y `/sbin/ip` pasa a ser el
BINARIO de iproute2 en vez del applet.
raíces kde 49→96 · gnome 39→86 · cosmic 43→88
nodos kde 301→356 · gnome 204→256 · cosmic 162→216
deuda 0 en los tres — no hubo que construir NADA, ya estaba todo sellado
colisiones nuevas al hidratar: CERO (los 28 .hammer-tmp son los de gmp/mpfr de antes)
⚠ `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.
`kde-rootfs` en el volumen se rehidrató con la herencia (11 G) para que el nombre canónico no quede
viejo — que es el error que este mismo día costó encontrar en GNOME y COSMIC. El rootfs FUNDIDO y la
imagen siguen siendo los de antes: rehacerlos es un paso aparte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
El usuario señaló que «perfil» suena a preset exclusivo y preguntó lo que hay que preguntar: si no
va a poder instalar KDE, GNOME y mirada a la vez y elegir en un greeter.
MEDIDO, comparando los dos rootfs hidratados que hay en disco (kde-rootfs 78.934 ficheros,
gnome-rootfs 19.955): 14.455 rutas están en LOS DOS, y de ésas **12.766 comparten INODO** — o sea
que son el mismo artefacto del store, no un conflicto. Sólo **1.689 (12 %) colisionan de verdad**.
⇒ Lo que impide instalar dos escritorios NO es el store, que ya los tiene conviviendo: es
proyectarlos al MISMO /usr. 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. Es el mismo cuadro de las dos poppler que targets.toml ya documenta, y el de gmp/mpfr que
dejó 28 .hammer-tmp al hidratar KDE hoy.
Dos caminos, no excluyentes: bajar las colisiones unificando lo duplicado (una glib, un dbus), o no
proyectar a un /usr único — que es literalmente lo que el SDD 18 ya propone («activar un nodo =
montar su composefs como /usr»). Con vistas, las 1.689 dejan de existir por construcción. El
greeter encaja solo: el arranque por grafo del ADR 0010 ya elige qué clausura activar.
Y queda anotado el corolario de orden: el paso 5 del plan (unificar imagen e instalador) construiría
sobre el supuesto de un solo escritorio a la vez. Hay que decidir FHS plano vs vista composefs ANTES
de unificarlos, porque es la diferencia entre «instalás uno» y «instalás los tres».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
PROPUESTA, nada implementado. Escrito a pedido del usuario mientras se tapaba el hueco de upower.
⚠ EL HALLAZGO QUE LO MOTIVA, y es peor de lo que parecía: `targets.toml` ya avisaba que
«kde/gnome/cosmic NO heredan base», pero la consecuencia no estaba escrita en ningún lado. Medida:
**de los 27 paquetes del perfil `base`, la clausura de escritorio-kde alcanza 2**. Y comprobado
contra el rootfs real de la imagen: NO hay `bash`, ni `sudo`/`doas`, ni `git`, ni `useradd`, ni
`gpg`, **ni `dhcpcd`** — o sea que la imagen no sabe pedir una IP. Lo que sí hay (`ip`, `mount`,
`fsck`) son APPLETS DE BUSYBOX: `/sbin/ip → ../bin/busybox`.
O sea que la respuesta a «¿abrir un escritorio es como si base no existiera?» es **sí**. Y la causa
es que hay DOS cosas llamadas base que nadie había distinguido por escrito:
· base de ARRANQUE (`metal-rootfs`): arje-zero + busybox. La imagen la funde. Existe.
· base de USERLAND (`[perfil.base]`): las 27. No la funde nadie.
El documento separa las cuatro capas (piso / escritorio / extras / toolbox CLI), explica que un
«metapaquete» YA EXISTE y se llama perfil, y nombra las tres cosas que le faltan para ser
instalable: herencia entre perfiles, publicación al repo firmado, y un verbo que resuelva una LISTA
y no un paquete.
Y plantea la única decisión que no es de implementación: instalar un escritorio REPRODUCIENDO
(coherente con que el canal no distribuya binarios, pero son horas en la máquina del usuario) o
HIDRATANDO artefactos firmados (segundos, pero es entregar binarios y activa entera la obligación
de licencias que se cerró hoy). La salida propuesta es la del ADR 0014: que existan las dos y que
reproducir sea lo que hace verificable a hidratar.
Nota de nomenclatura, porque el usuario preguntó: `.swm` NO es residuo del renombre — significa
«Software Mutación» y describe lo que el fichero ES. El verbo ya es el correcto, `takana install`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
