takana/docs/plan-apps-usuario-final.md

# Plan — apps de usuario final (montón A del ADR 0015), MEDIDO

**Fecha de la medición:** 2026-09-03 · **Catálogo contra el que se midió:** 1079 recetas
(corpus + las cuatro colas) · **Instrumento:** `makedepends`+`depends` del APKBUILD de Alpine de
cada candidata, cruzados contra los nombres de receta que existen en el disco.

## Por qué existe este documento

El [ADR 0015](adr/0015-imagenes-ajenas.md) parte las apps que faltan en tres montones y dice del
**A** —Firefox, Chromium, LibreOffice, mpv, GIMP, Inkscape, Blender, OBS— que no lo bloquea *«nada
estructural: son Wayland-nativos y compilables. Falta escribirlas»*, y propone el orden
**mpv → OBS → Firefox**.

`mpv` se escribió el 2026-09-03 y esa parte se confirmó. Al ir por el segundo, la medición
**desmiente la premisa para el resto del montón**: OBS y Firefox no están a una receta de distancia,
están detrás de muros que esta distro levantó a propósito. Este documento deja el dato escrito para
que la decisión se tome mirándolo y no de memoria.

## Cómo leer la tabla

Dos columnas, y **la que importa es la segunda**:

- **recetas que faltan** — cuántos `makedepends` de Alpine no tienen receta acá. Es una **cota
  superior floja**: Alpine construye con todo activado y nosotros no. El control lo da `mpv`, que
  YA ESTÁ SELLADA y aun así aparece con 16 faltantes — son exactamente las perillas que su receta
  apaga a propósito (jack, sndio, libbluray, zimg, rubberband…). O sea: un número alto no prueba
  que sea caro.
- **muros de diseño** — dependencias que NO son «una receta más», sino decisiones ya tomadas de
  esta distro: GTK3 aparcado, X11 al tacho, Qt6 que vive sólo en `incoming-kde`, toolchain wasi
  inexistente. **Un muro no se paga escribiendo una receta: se paga cambiando una decisión.**

## La tabla

| app | faltan | muros | veredicto |
|---|---:|---|---|
| ~~wf-recorder~~ | — | — | ✅ **SELLADA 2026-09-03** (b3:25caa359), con audio. Se destrabó al promover pipewire al corpus. Sólo en `escritorio-sway`: captura por `wlr-screencopy` y KWin/mutter no lo implementan. |
| ~~imv~~ | 7 | **GL de escritorio** | ❌ **BLOQUEADA 2026-09-03** — el muro no lo veía este método; ver abajo. Reemplazada por `swayimg`, sellada el mismo día. |
| ~~swayimg~~ | — | — | ✅ **SELLADA 2026-09-03** (b3:9bcd39c1, **5.5**), en las CUATRO imágenes. Visor sin GL: rasteriza a `wl_shm`. Trae backend DRM de yapa. |
| ~~luajit~~ | — | — | ✅ **SELLADA 2026-09-03** (b3:115d4c1c). Escrita para destrabar swayimg 5.x; mpv también la prefiere. |
| ~~zathura~~ | — | — | ✅ **SELLADA 2026-09-03** (b3:9c5eac92) + `zathura-pdf-poppler`. **Es GTK4, no GTK3**: upstream vació girara. En gnome/cosmic/sway; **NO en KDE**, por colisión de poppler. |
| ~~mupdf~~ | 9 | X11 **y GL de escritorio** | ❌ **BLOQUEADA 2026-09-03.** La nota era falsa: `mupdf-gl` **sí** es un muro — su `platform/gl/` va sobre GLUT + OpenGL de escritorio, el mismo muro que imv. mupdf **no tiene visor Wayland**: sus dos UIs son `mupdf-x11` y `mupdf-gl`. El motor (`libmupdf`+`mutool`) no tiene muros, pero no hace falta: el PDF ya lo da poppler. |
| ~~inkscape~~ | 14 | **GTK3** (en la release) | ❌ **BLOQUEADA 2026-09-03.** Era GTK3 encubierto, como se sospechaba: `INKSCAPE_1_4_4` pide `gtkmm-3.0>=3.24` **y** `gtk+-3.0>=3.24`. `master` **sí** migró a GTK4 (`gtk4>=4.14`, `gtkmm-4.0>=4.13.3`) pero está sin publicar; y de todos modos el catálogo **no tiene NI UN binding C++**: faltan sigc++, glibmm, cairomm, pangomm y gtkmm enteros. |
| *mpv* | *16* | *X11* | *YA SELLADA — es el control del método, no una candidata.* |
| **gimp** | 18 | **GTK3**, X11 | GIMP 2.10 es GTK2/3. Fuera de alcance mientras GTK3 esté aparcado. |
| **obs-studio** | 20 | **Qt6**, X11 | ver abajo. |
| **firefox** | 26 | **GTK3**, X11, **wasi** | ver abajo. |
| **chromium** | 38 | **GTK3**, **Qt6**, X11 | peor que Firefox por todos lados. |
| **libreoffice** | 59 | **GTK3**, **Qt6**, X11 | 59 recetas y tres muros. No es un ticket, es un año. |

## ⚠ El defecto del método, encontrado al usarlo (y lo que destapó)

La columna «recetas que faltan» pregunta **¿existe esta receta en el disco?** y esa es la pregunta
equivocada. La correcta es **¿la alcanza el consumidor?** — porque una receta resuelve sus deps
sibling-first (su propia cola) y después el catálogo PADRE, **nunca una cola hermana**.

Se descubrió al ir a escribir `wf-recorder`, que la tabla daba en 0/0: su `makedepends` pide
`pipewire-dev` y `pulseaudio-dev`, los dos existen… **en las tres colas de escritorio y en ninguna
en el corpus**. Una app del corpus no los ve. wf-recorder construye igual (`-Dpulse=disabled
-Dpipewire=disabled`, `have_audio=false`) pero graba **sin sonido**, y no tiene backend ALSA con el
que caerse.

### Lo que eso destapa, que es más grande que wf-recorder

> **El corpus no tiene ningún cliente de audio salvo ALSA.** `libpipewire-0.3` y `libpulse` viven
> sólo en `incoming-{kde,gnome,cosmic}`. Toda app multimedia que llegue al corpus va a chocar acá.

Ya chocó dos veces en un día: `mpv` terminó con `--ao=alsa` en vez de su salida nativa de PipeWire
(y por eso hubo que dar vuelta `-Dpipewire-alsa` en las tres pipewire, que fue el arreglo correcto
pero fue un rodeo), y ahora `wf-recorder` se queda mudo.

**DECIDIDA Y HECHA el 2026-09-03 — opción 1, con una salvedad medida.** Lo que sigue queda como
registro de por qué. La decisión era: promover UNA pipewire al corpus. Construye
—el corpus tiene su propia `glib`, `dbus` y `pcre2`— pero el problema no es construirla: es que una
imagen que hidrate `corpus/pipewire` **y** la de su cola pondría dos `libpipewire-0.3.so` distintas
en la misma ruta, que es la enfermedad de las dos glib. Las salidas posibles, para pensarlas
despierto:

1. **Una sola pipewire, en el corpus, y las tres colas jubilan la suya.** Es lo más limpio y es lo
   que ya se hizo con otras 13 copias que sellaban igual — pero éstas NO sellan igual (difieren en
   glib/dbus/pcre2), así que hay que decidir cuál gana y volver a sellar wireplumber y los portales
   de las tres colas.
2. **Aceptar ALSA como la única ABI de audio del corpus**, que es lo que hoy quedó funcionando de
   hecho: `-Dpipewire-alsa=enabled` hace que un cliente ALSA desemboque en PipeWire. Barato y ya
   está hecho; el precio es que las apps del corpus nunca usan la API nativa (sin control por-stream,
   sin metadata de sesión) y que las que sólo hablan pulse/pipewire —wf-recorder— quedan afuera.
3. **Que las apps multimedia vivan en las colas**, una copia por escritorio. Es lo que la estructura
   empuja hoy y es exactamente lo que no queremos para una app que sirve a las cuatro imágenes.

### Cómo se resolvió

Ganó la **opción 1**, y salió barata porque la variante de COSMIC ya resolvía su cierre entero
contra el catálogo padre: `recipes/pipewire.toml` sella el MISMO hash que tenía en la cola. Con ella
subieron `libsndfile` y `dbus-shared` (duplicados exactos). 9 copias de cola jubiladas, **5
rebuilds**.

Lo que hizo segura la promoción fue una medición, no un argumento: **ningún pipewire enlaza glib**
—sus NEEDED son `libdbus-1.so.3`, `libpulse.so.0`, `libsndfile.so.1`— así que `libpipewire-0.3.so`
se comparte entre las cuatro imágenes sin repetir el episodio de las dos glib.

**Y la salvedad, que es la parte que valía la pena medir:** `pulseaudio` NO se promovió.
`libpulse-mainloop-glib.so.0.0.6` mide **45.712 bytes** en la variante de GNOME (NEEDED
`libglib-2.0.so.0`) y **2.455.600** en la del corpus, que se traga la glib ESTÁTICA. Esa dentro del
proceso de gnome-shell —que ya carga la glib sombra dinámica— es el cuadro de colord. Las tres
pulseaudio se quedan: son variantes deliberadas. Sin esa salvedad los rebuilds habrían sido 8,
incluido `gnome-shell`.

La regla general que sale de acá, y sirve para la próxima promoción:

> **Enlazar contra una variante y correr contra otra es legítimo cuando lo que cruza es un SONAME**
> (misma ABI). Lo que no se puede es **hidratar dos artefactos distintos en la misma ruta**. Por eso
> pipewire se puede compartir y pulseaudio no.

Consecuencias inmediatas: `mpv` pasó a `-Dpipewire=enabled` (con ALSA detrás, para imágenes sin
demonio) y `wf-recorder` se escribió y selló el mismo día.

## ⚠ EL TERCER DEFECTO DEL MÉTODO: la receta existe, es alcanzable, y aun así no sirve

El defecto anterior era «¿existe la receta?» ≠ «¿la alcanza el consumidor?». Al ir a escribir `imv`
apareció un **tercer eje**, y es el peor de los tres porque las dos preguntas anteriores dan que sí:

> **La receta existe, el consumidor la alcanza, y la VARIANTE que se construyó no publica la ABI
> que hace falta.**

`imv` pide OpenGL. `mesa` existe, está en el corpus, y cualquier receta lo alcanza. Pero:

- `imv/src/canvas.c` hace `#include <GL/gl.h>` y dibuja con `glBegin` / `glOrtho` /
  `GL_TRIANGLE_FAN` / `GL_TEXTURE_RECTANGLE`, o sea **OpenGL de función fija**, perfil de
  compatibilidad. No existe equivalente en GLES: no es una perilla, es otra API.
- Su `meson.build` hace `gl_dep = dependency('gl', required: false)` y, si no la encuentra,
  `dependency('opengl')` **sin `required: false`** ⇒ el configure muere.
- Y esta distro **no tiene ningún proveedor de OpenGL de escritorio**. Medido en los artefactos
  sellados, no supuesto: las **tres** variantes de mesa (`mesa`, `mesa-swrast`, `mesa-llvmpipe`)
  llevan `-Dglx=disabled -Dglvnd=false`, y sus artefactos publican `libEGL.so.1`, `libGLESv2.so.2`,
  `libgbm` y `egl.pc`/`glesv2.pc`/`gbm.pc` — **ni un `libGL.so*`, ni `gl.pc`, ni `opengl.pc`**.
  No hay receta `libglvnd` en ninguna cola.

**La trampa fina, y es la parte que hay que recordar:** mesa SÍ instala `/usr/include/GL/gl.h`
(el header viene con `-Dopengl=true`). O sea que una app así **compila entera** y muere recién al
LIGAR. Un triaje que mire headers da verde.

### Qué costaría darlo vuelta (para que la decisión se tome con el número)

El camino que el propio `meson.build` de imv nombra —«libglvnd fallback for pure-wayland systems»—
es autorar `libglvnd` (que provee `libOpenGL.so`/`opengl.pc`) y reconstruir mesa con `-Dglvnd=true`.
Eso es **radio 139 dependientes directos** sobre `mesa`, y además convierte a libglvnd en pieza
obligatoria de las cuatro imágenes: sin ella no hay EGL. Es una decisión de distro, no un ticket de
visor de imágenes.

### La salida, que resultó mejor que el original

`swayimg` cubre el mismo caso de uso **sin tocar GL**: rasteriza a un buffer y lo entrega por
`wl_shm`. Sus deps requeridas (xkbcommon, fontconfig, freetype2, wayland, wayland-protocols) ya
estaban todas en el corpus ⇒ **cero recetas nuevas**. Y trae un backend **DRM** que muestra imágenes
en una TTY pelada, sin compositor, que es exactamente lo que le falta al instalador.

Entró primero como **4.7** —la última sin Lua— porque desde la 5.0 `dependency('luajit')` es
obligatoria y no había receta (la `lua5.2` del OSC de mpv es otra ABI). Se escribió `luajit` el mismo
día y subió a **5.5**. La cadena quedó verificada de punta a punta: `swayimg -e` reporta
`Lua 5.1 · jit=true · LuaJIT 2.1.1787165859`, que es exactamente el `relver` de nuestra receta.
`luajit` queda además disponible para mpv, que la prefiere sobre 5.2.

**Regla que sale de acá, para el próximo triaje de apps:** la pregunta no es «¿existe la receta?»
ni sólo «¿la alcanza?», sino **«¿la variante sellada publica el `.pc` y el `.so` que el consumidor
pide?»**. Se contesta mirando el artefacto, no el catálogo.

Y como acá cada punto ciego se convierte en un guardián, esa pregunta ya tiene instrumento:
**`scripts/provee.py`**, que indexa los `.pc` y las librerías de TODOS los artefactos sellados y
contesta quién publica cada nombre y desde qué colas se alcanza. Los tres defectos del método caen
con un solo comando:

```sh
scripts/provee.py --desde corpus gl opengl     # ✗ nadie lo publica  → exit 1  (el caso imv)
scripts/provee.py exiv2 librsvg                # ✓ existen, alcanzables SÓLO desde su cola
```

Es el hermano de build de `vigia-sonames.py`, que cubre la mitad de runtime. **El triaje de la
próxima app empieza por acá**, no por contar `makedepends` contra `recipes/*.toml`.

## El montón A quedó AGOTADO de cosas sin muro (2026-09-03)

Con `zathura` cerrada, se re-triaron con `scripts/provee.py` las tres candidatas que la tabla daba
como baratas o dudosas. **Las tres son muro**, y ninguna lo era por el motivo que decía la tabla:

- **imv** → no hay proveedor de OpenGL de escritorio (sección de arriba). Sustituida por `swayimg`.
- **mupdf** → sus DOS visores son X11 o GLUT+OpenGL de escritorio. No tiene UI Wayland.
- **inkscape** → la release es GTK3; el `master` con GTK4 está sin publicar y además pide toda la
  torre de bindings C++ que este catálogo no tiene (`provee.py` da ✗ en sigc++-2.0, glibmm-2.4,
  cairomm-1.0, pangomm-1.4, gtkmm-3.0 **y** gtkmm-4.0).

**Todo lo que queda del montón A está detrás de UNA de cuatro decisiones**, no de trabajo de
recetas: GTK3 (inkscape-release, gimp, firefox), Qt6-en-el-corpus (obs), OpenGL de escritorio
(imv, mupdf-gl) o X11 (chromium, mupdf-x11). Ver «los dos veredictos» abajo y el orden propuesto.

## ⚠ Lo que SÍ estaba roto y no era falta de recetas: imágenes sin terminal

Al terminar zathura se cruzó la membresía de los cuatro perfiles contra una lista de emuladores de
terminal, editores y gestores de ficheros. El resultado no tiene nada que ver con el montón A y es
más grave que cualquier app que falte:

| perfil | terminal | editor | archivos |
|---|---|---|---|
| `escritorio-cosmic` | cosmic-term | cosmic-edit | cosmic-files |
| `escritorio-sway` | foot | vim | — |
| `escritorio-gnome` | **—** | **—** | — |
| `escritorio-kde` | **—** | **—** | — |

Es la lección de `foot` otra vez y a mayor escala: sway llegó a 121/121 **sin emulador de terminal**
porque nadie lo declaraba, y la métrica de clausura no lo puede ver porque mide lo DECLARADO.

**GNOME arreglado el 2026-09-03 con CERO recetas nuevas**: `foot` y `helix` viven en el corpus, ya
estaban selladas y **no las declaraba ningún perfil**. foot es Wayland puro sobre `xdg-shell` (no
pide protocolos de wlroots) así que corre bajo mutter; su único NEEDED es `libc.so`.

**KDE es un hallazgo aparte y NO se tocó**: tiene **22 apps con `.desktop` selladas en su cola y sin
declarar** —konsole, dolphin, kate, okular, spectacle, ark, gwenview, systemsettings, kcalc…— y
además le faltan `plasma-desktop`, `plasma-nm`, `plasma-pa`, `powerdevil` y `kscreen`, o sea red,
audio, energía y pantalla. Su perfil son **13 raíces de ARRANQUE EN METAL**, no la imagen de
escritorio completa (ésa se hidrató aparte, por hash). Reordenarlo es decisión del frente KDE.

## Los dos veredictos que corrigen al ADR

### Firefox NO es montón A

Su APKBUILD pide `gtk+3.0-dev` — **Firefox no tiene backend GTK4 ni lo va a tener a corto plazo**, y
GTK3 es una de las tres deudas que el frente GNOME aparcó por diseño.

⚠ **CORREGIDO 2026-09-03: el X11 de Firefox NO es un muro.** Se listaba como tal por los `libxt` y
`libxcomposite` del APKBUILD, pero en el árbol de Gecko todo el código X11 está detrás de
`CONFIG["MOZ_X11"]` (`widget/gtk/moz.build:131`): es una PERILLA de build, no una dependencia
estructural, y hay builds Wayland-only. El muro real de Firefox es **GTK3**, más un
**toolchain wasi** (`wasi-sdk`, `wasi-compiler-rt`) que no existe en el
corpus, más `nodejs`, `icu`, `nss/nspr`, `clang/llvm/lld` versionados y `cbindgen`.

La memoria del repo decía que a Firefox «le falta subir el techo MSRV». Eso es cierto **y es lo
menor**: el bloqueo real es GTK3.

**Consecuencia estratégica, que es la decisión que hay que tomar despierto:** todos los navegadores
del mundo Linux son o GTK3 (Firefox y derivados) o Chromium (que además arrastra Qt6 y GTK3 en
Alpine). Entonces **«tener navegador» no es un ticket del montón A**: es elegir entre

1. **autorar el stack GTK3** —revierte una decisión de diseño y reabre GIMP/Inkscape de paso—, o
2. **darle el navegador a [qorpa](adr/0015-imagenes-ajenas.md)**, o sea tratarlo como montón B: el
   navegador corre en la imagen ajena, hablando Wayland por socket.

La opción 2 es coherente con todo lo demás que ya se decidió, y tiene una ventaja que conviene
nombrar: el navegador es *justamente* el proceso al que menos ganas dan de darle el sistema entero.

### OBS no puede ser una app del corpus

Pide `qt6-qtbase-dev`, `qt6-qtbase-private-dev` y `qt6-qtsvg-dev`, y **Qt6 vive sólo en
`incoming-kde/`**. Una receta resuelve sibling-first y después el catálogo padre: desde el corpus no
se alcanza una cola. O sea que OBS hoy sólo puede existir **dentro de la cola de KDE**, y entonces
no es una app de las cuatro imágenes sino una app de KDE. Súmese X11 (`libx11`, `libxcb`,
`libxcomposite`, `libxinerama`) y 20 recetas nuevas (`libdatachannel`, `librist`, `libsrt`,
`mbedtls`, `rnnoise`, `x264`, `luajit`, `swig`, `vlc`…).

**Si lo que se quiere es grabar la pantalla** —que es el 80% de para qué se instala OBS— eso ya está
al alcance de la mano: **`wf-recorder` sale con CERO recetas faltantes y cero muros**, porque su
cierre (wayland, ffmpeg, libdrm) quedó completo cuando entró mpv.

## Orden propuesto, en reemplazo del del ADR

1. ✅ **mpv** — hecho (2026-09-03).
2. **decisión de audio del corpus** (el ⚠ de arriba). Destraba wf-recorder y le da a mpv
   su salida nativa. Es una decisión, no una campaña.
3. **wf-recorder** — inmediato una vez tomada esa decisión; cubre el caso de uso principal de OBS.
4. ✅ **visor de imágenes** — hecho (2026-09-03), pero con **`swayimg` 4.7 y no `imv`**: imv está
   bloqueada por el muro de GL de escritorio (sección de arriba). En las cuatro imágenes.
4b. ✅ **`luajit`** — hecha (2026-09-03). Destrabó swayimg 5.5 y queda disponible para mpv.
5. ✅ **zathura + backend PDF** — hecho (2026-09-03). **La sospecha de GTK3 era falsa**: upstream
   VACIÓ `girara` (en 2026.07.18 son siete `.c` de utilidades, cero GTK) y toda la UI se mudó a
   zathura, que pide GTK4 >= 4.12 — que está en el corpus. Costó 5 recetas nuevas
   (`girara`, `xxhash`, `poppler-glib`, `zathura`, `zathura-pdf-poppler`) + 4 promociones gratis al
   corpus (`json-glib`, `lcms2`, `glib-shared`, `pcre2-shared`, `bzip2-shared`).
   **No va en `escritorio-kde`**: su backend necesita una poppler con `ENABLE_GLIB=ON` y esa imagen
   ya trae la de Qt6 vía okular; las dos instalan `/usr/lib/libpoppler.so.146`.
6. ✅ **terminal y editor en GNOME** — hecho (2026-09-03), cero recetas: `foot` + `helix` del
   corpus, que ya estaban selladas y sin declarar. Ver la sección de arriba.
7. **DECISIÓN pendiente, y ahora bloquea a TODO lo que queda** — no es trabajo de recetas:
   **(a)** autorar el stack GTK3 (destraba inkscape-release, GIMP y Firefox de una vez),
   **(b)** dárselo a [qorpa](adr/0015-imagenes-ajenas.md) como montón B, o
   **(c)** autorar la torre de bindings C++ (sigc++/glibmm/cairomm/pangomm/gtkmm-4) y seguir el
   `master` sin publicar de Inkscape.
   Hasta que se tome, el montón A no tiene ningún ticket barato: está agotado.
8. **Aparte y sin decisión: las 22 apps de KDE selladas y sin declarar** (sección de arriba). No
   cuesta un build — cuesta acordarlo con el frente KDE.

OBS, Firefox, Chromium, GIMP y LibreOffice **salen del montón A** hasta que se decida GTK3 o qorpa.
Que se llame montón A y no se pueda construir es peor que no tenerlo en la lista: es deuda fantasma,
la misma figura que la terna de GNOME que había que sacar de `targets.toml` para que el grafo dejara
de mentir.

## Reproducir la medición

⚠ **Ya no se reproduce así.** Lo que sigue describe el método ORIGINAL, que es el que falló las
tres veces documentadas arriba; se deja escrito para que se entienda de dónde salieron los números
de la tabla. El triaje de una app nueva se hace hoy cruzando sus `makedepends` contra
`scripts/provee.py --desde corpus`, que pregunta por el artefacto y no por el catálogo.

`/tmp/.../triaje-apps.py` fue un script de una sola vez; si hace falta repetirlo, lo que hace es:
bajar el APKBUILD de cada candidata, extraer `makedepends`/`depends`, quitarles el sufijo `-dev`, y
cruzar contra `recipes/*.toml` + `recipes/incoming-*/*.toml`, separando una lista fija de nombres
que son muros de diseño (gtk+3.0, qt6-*, lib X11, wasi-*). No se guarda en `scripts/` porque la
lista de candidatas es del momento, no un invariante que valga la pena vigilar.

---

# ADENDA 2026-09-13 — el censo, el muro de GL revisado, y la respuesta a «¿Electron?»

Sale de tres preguntas del usuario en una sesión: *¿es congruente empaquetar GenOffice?*, *¿teníamos
planeado compilar Electron?*, *¿qué apps muy usadas valdría la pena replicar de cero en vez de
incluirlas?*. Las tres se contestaron midiendo, y dos mediciones **corrigen cosas escritas arriba**.

## 1. El censo: de ~50 apps muy usadas, el catálogo tiene 9

Cruzado contra los 1158 nombres de receta del disco (corpus + las cuatro colas):

**Están (9):** `firefox`, `mpv`, `obs-studio`, `zathura`, `okular`, `gwenview`, `dolphin`, `ark`,
`spectacle` — y **cinco de esas nueve son de KDE**, o sea que sólo llegan a una de las cuatro
imágenes.

**No están:** gimp, inkscape, krita, darktable, blender, audacity, kdenlive, shotcut, vlc, chromium,
thunderbird, evolution, libreoffice, calligra, scribus, calibre, transmission, qbittorrent, deluge,
filezilla, remmina, wireshark, virt-manager, gparted, keepassxc, bitwarden, signal-desktop,
telegram-desktop, element-desktop, fractal, discord, slack, zoom, spotify, steam, lutris, wine,
vscode, zed, sublime-text, obsidian, logseq, anki, gnucash, homebank, thunar, nautilus, pcmanfm,
file-roller, flameshot.

## 2. ⚠ CORRECCIÓN al «tercer defecto del método»: el muro de GL se movió, y luego se disfrazó

La sección de arriba dice, con fecha 2026-09-03, que **ninguna cola publica `libGL.so` ni `gl.pc`** y
que por eso toda app de GL de escritorio está bloqueada. **Eso dejó de ser cierto al día siguiente** y
conviene no repetirlo de memoria:

```
scripts/provee.py --desde corpus gl opengl        # corrido el 2026-09-13
  gl        ✗ NADIE LO PUBLICA en ninguna cola
  opengl    ✓ corpus/libglvnd  ⇒  libOpenGL.so.0  opengl.pc
```

`recipes/libglvnd.toml` existe desde el **2026-09-04**, escrita para OBS, y hace la partición que
ordena el problema —que arriba estaba mezclado en una sola fila:

- **`libGL.so.1` = GL *más GLX*** en una sola librería ⇒ **implica X11**. Encenderlo metería
  `libX11`/`libxcb`/`xorgproto` —hoy sólo en `incoming-kde`— **en el CORPUS**, o sea en las cinco
  imágenes, para servir a una app. Eso sí sería contraproducente: es reabrir X11-al-tacho.
- **`libOpenGL.so.0` = GL de escritorio pelado**, sin ventana ni plataforma, con el contexto creado
  por EGL. **No contradice ninguna decisión de la distro.** Es la que se eligió.

⚠ **Pero la campaña quedó a medias, y eso vale más que la buena noticia.** Las tres recetas de mesa
siguen con `-Dglvnd=false`. Medido en el rootfs de KDE ya hidratado:

| | mesa | libglvnd |
|---|---|---|
| `/usr/lib/libEGL.so.1` | → `libEGL.so.1.0.0`, **1.440.624 B** (el driver) | → `libEGL.so.1.1.0`, **323.144 B** (puro despacho) |
| `libEGL_mesa.so.0` + `/usr/share/glvnd/egl_vendor.d/` | ✗ | ✗ |

Las **dos** están declaradas en `escritorio-kde` ⇒ dos `libEGL.so.1` distintos en la misma ruta. Hoy
gana el de mesa —por orden de hidratación, no porque nada lo guarde— y el de glvnd queda huérfano al
lado. La propia receta de `libglvnd` avisaba de esto: *«mesa se reconstruye en la MISMA campaña, no
después»*.

**Y OBS, que fue la razón de escribir libglvnd, no la usa en runtime.** `libobs-opengl.so` sale con
`NEEDED libEGL.so.1` y nada más; sus símbolos indefinidos son todos `egl*`, **ni un `gl[A-Z]` sin
resolver** ⇒ su `glad` resuelve los punteros por `eglGetProcAddress` contra la EGL de mesa. glvnd
está en la imagen satisfaciendo un requisito **de enlace** (el `OpenGL::GL` de CMake) y es **inerte**.

⇒ **El estado real del muro**: `provee.py` dice `opengl ✓` y eso es verdad **de enlace**. En runtime
no hay vendor de GL de escritorio registrado. Una app que de verdad llame por `libOpenGL.so.0`
encontraría una tabla de despacho vacía. El muro pasó de *«no enlaza»* a *«enlaza y no corre»*, que
es el modo de fallo más caro de esta casa. **Terminarlo es re-sellar las tres mesa con
`-Dglvnd=true` en un solo movimiento**, y su precio ya está medido: radio grande sobre `mesa` y
libglvnd pasa a ser pieza obligatoria de las cuatro imágenes.

**Corolario para la tabla de arriba:** `darktable` estaba mal clasificada como caso de GL. No lo es —
su UI es GTK3+cairo y OpenCL es opcional. Su muro es la **cola de deps**: faltan `lensfun`,
`libgphoto2`, `openexr`, `imath`, `libraw`, `osm-gps-map`, `portmidi`, y `exiv2`/`librsvg`/
`libsecret`/`colord` existen **sólo en colas** (inalcanzables desde el corpus). Es un frente de ~8
recetas, no un muro. **`blender` sí es el caso de GL** (pide 4.3 core).

## 3. Electron: nunca estuvo planeado, y el sustituto ya está construido

`grep -rniE 'electron' docs/ recipes/` da **cero coincidencias**. No hay plan, ni ADR, ni ticket — y
la tabla de arriba explica por qué sin nombrarlo: `chromium` es la peor fila del montón A (38 recetas
+ GTK3 + Qt6 + X11), y Electron es Chromium **más** Node.

### No existe un «Electron con base Firefox», y el SDD 26 §1 dice por qué

> Gecko **no tiene API de embebido** en escritorio desde que murió XULRunner; GeckoView existe y es
> de Android. ⇒ un envoltorio de Gecko es necesariamente **chrome-level**.

Por eso los intentos históricos (Positron, Mozilla 2016) no cuajaron. **Pero eso es exactamente lo
que es `atuq`, y ya está hecho:**

| pieza de Electron | equivalente en `atuq` | estado |
|---|---|---|
| runtime Chromium | Gecko como **artefacto DERIVADO** de `firefox`, sin fork de fuente | ✅ sellado, en las 4 imágenes |
| UI en HTML/JS | `omni.ja` re-empacado + `userChrome.css` + `distribution/extensions/` | ✅ SDD 26 §4.g |
| lado Node (acceso al sistema) | **host de native messaging en Rust** | ✅ §7.quater, 2026-09-10 |
| IPC | `connectNative`, con el contrato MEDIDO | ✅ §7.bis |

⇒ **Lo que falta para que `atuq` sea una plataforma de apps y no sólo un navegador es chico**: un
modo SSB (una ventana, sin barra, con su icono y su `.desktop`) y una clase de receta «app de atuq».
Eso es más barato que **un solo** port de Electron, y destraba una familia entera en vez de un
programa.

### GenOffice, concretamente

Electron + TypeScript + React, sidecar Rust para xlsx, **Apache-2.0** salvo `ee/` (licencia
Enterprise aparte), en `github.com/genspark-ai/genoffice`. Su README dice que acepta **cualquier
endpoint OpenAI-compatible, incluidos servidores de modelo locales**.

- **La mitad de IA está resuelta y es una línea de configuración**: `llama-cpp` sirve
  `/v1/chat/completions` y `/v1/embeddings`, y **ya viaja en los cuatro escritorios** junto con
  `ia-modelo-chat`. Apuntarlo a `http://127.0.0.1:8080/v1` elimina Genspark, la API key y la salida
  del documento de la máquina.
- **La mitad de runtime no**: no hay Electron ni lo va a haber. La vía es **qorpa** —
  `docs/state/qorpa-imagenes.toml` ya cura `ubuntu-base` y GenOffice publica `.deb`.
- ⚠ **Y el muro real no es el empaquetado, es el MODELO.** El pineado es Qwen2.5-1.5B-Instruct
  Q4_K_M (20,1 tok/s en CPU, elegido por peso y licencia). Para reescribir un párrafo alcanza; para
  lo que GenOffice llama IA agéntica sobre un `.xlsx`, un 1.5B da basura. Conectarlo funciona; que
  **sirva** pide pinear un modelo mucho mayor, y eso es su propia unidad de trabajo (y RAM).

## 4. Qué vale la pena REHACER en vez de incluir

El criterio, porque sin criterio esto es una lista de deseos:

> **Rehacer sólo cuando el upstream está bloqueado por algo ESTRUCTURAL y el valor vive en un
> protocolo o formato abierto, no en el código.** Si no: empaquetar, o enjaular.

**Empaquetar — el muro cayó o nunca existió:**

- **`thunderbird`** es el más desaprovechado: **es Gecko**. Misma cadena que `firefox`, que ya
  construye. Ningún muro nuevo, sólo otro build largo. Es el cliente de correo gráfico más barato
  que este catálogo puede tener.
- **`gimp`**: estaba bloqueado por GTK3 y **`gtk3` ya está sellada** (Wayland-only). Pide re-triaje
  con `provee.py` antes de prometer nada.
- **`krita`, `kdenlive`, `qbittorrent`, `keepassxc`, `calibre`**: son Qt6, y Qt6 está **completo en
  `incoming-kde`**. Son recetas de cola, no muros — pero sólo llegan a la imagen KDE.
- **`fractal`** (Matrix, GTK4+Rust) y **`transmission`**: sin muro conocido.

**Enjaular (qorpa), no rehacer:** vscode, discord, slack, signal, obsidian, zoom, spotify, steam,
**genoffice**. Y **blender**, porque la jaula trae su propia mesa glibc y **esquiva la campaña de
glvnd por completo**.

**Rehacer desde tawasuyu — la lista corta que pasa el criterio:**

1. **El shell de apps sobre `atuq`** (§3). No es una app: es el runtime. Máximo apalancamiento.
2. **Bóveda / gestor de contraseñas.** KeePassXC es Qt y Bitwarden es Electron, pero el valor está
   en el formato KDBX y en la integración con el navegador — y **esa mitad, que es la cara en todos
   lados, ya está construida**: `agora` (Ed25519), `qullqa` y el host de native messaging.
3. **Cliente Matrix nativo — sólo si `fractal` no construye.** Medir antes de escribir.

El precedente que dice que el método funciona es propio: **torrent (SDD 26 §6.9) y medios (§6.6) se
rehicieron como demonios Rust en vez de empaquetar transmission y vlc, y los dos están cerrados.**

⚠ Y la advertencia que el SDD 26 §2 ya pagó: portar un upstream vivo compra **su cinta de correr**
(*«el costo de Zen no es el motor: es el rebase cada cuatro semanas»*). Un port de GenOffice es una
relación, no una receta.