SDD 27 §8: metapaquete y no perfil — medido qué impide tener KDE y GNOME a la vez

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

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

@@ -1,4 +1,4 @@
-# SDD 27 — Perfiles instalables: del rootfs hidratado al `takana install escritorio-kde`
+# 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
@@ -127,3 +127,54 @@ El verbo, en cambio, ya es el correcto: **`takana install`**.
 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](18-wawafs-store-vivo.md) 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».