Trinity en Void Linux: un pedido que llevaba 6 años sin respuesta y que pudo resolver Entropía binaria.

Voy a empezar por el final, porque el final se describe con una sola línea:

ln -s /opt/trinity/lib64 /opt/trinity/lib

Ese enlace simbólico: un archivo que apunta a otro archivo, una sola línea de comandos, 2 simples rutas.

Entre el momento en que empecé este proyecto y el momento en que escribí esa línea pasaron 25 horas, treinta y pico de dependencias descubiertas de a una, 4 días de trabajo incluyendo madrugadas, yendo a laburar y durmiendo poco, 3 intentos serios de abandonar el proyecto, y el rescate de la casualidad misma, al poder ver un escritorio que arrancaba sin bordes, sin botones, sin estilos, sin acceso a las aplicaciones vía IGU (GUI), y sin poder abrir -incluso valiéndome de la terminal- varios de los programas que yo sabía que estaban instalados y que funcionaban (como Firefox, por ejemplo)... todo por un symlink que faltaba.

Pero vamos por partes.

Por qué me metí en esto.

Plasma, desde hace tiempo, ya no me parece una opción. Y no lo digo por la interfaz, sino por su eterno estado verde, por aquéllo a lo que apunta, y más aún por lo que hoy, indiscutiblemente, representa.

KDE 3 es (y era) coherente. Tiene una idea de lo que un escritorio debe ser: lugares para que puedas poner tus cosas en donde vos quieras, y un entorno que te obedece. No hay un diseñador decidiendo por vos si este botón "distrae", o si hay que abrazarse ciegamente a tecnologías inmaduras a partir de "tal momento", sin importar lo que opine la mitad de la gente. Después vino Plasma, y con Plasma vino el rumbo. O vinieron juntos, quizás premeditadamente.

Mirá la línea temporal: Windows 8 saca su "novedad", el escritorio Metro (baldosas planas colorinchudas pensadas para ser tocadas con el dedo en una pantalla en la cual nadie iba a terminar tocando nada). Windows 10 lo des-groseriza bastante y arma su escritorio. Y Plasma, que supuestamente era la alternativa libre, ¿qué hizo? Pues... fue detrás (y sigue yendo). Los mismos planos, la misma estética de baldosa, la misma idea de que menos es más... hasta que menos, ya fue la nada misma.
No siguió su propio camino: siguió el de Redmond, siempre corriéndola de atrás.
¿Viste cómo falla al intentar descargar temas?
¿Y qué me decís al intentar descargar íconos?
¿Y al intentar descargar decoraciones de ventana, fondos de escritorio y cursores de ratón?
Y encima: Wayland por omisión, systemd integrado hasta el caracú(lo), cada vez más pesado, cada vez más dependiente de decisiones corporativas que se toman en lugares en donde nosotros no estamos. Es el software libre "corporativo-amigable" del que vengo hablando hace años.

Trinity fue (y es) un intento de rescate de KDE antes de su transformación en Plasma: un fork de KDE 3.5, nacido en 2010, cuando "KUbuntu" (que hace rato que debería llamarse "PUbuntu", por coherencia) se pasó a Plasma 4 y Timothy Pearson dijo "ya fue suficiente". Hoy lo lidera Slávek Banko y sigue produciendo lanzamientos.
Y acá va un dato que me parece hermoso, fijate a ver si compartís conmigo: Trinity lleva más años vivo como bifurcación (fork) que lo que KDE 3 vivió como versión oficial. Un escritorio de 2001, bifurcado en 2010, con lanzamientos estables y frecuentes en 2026, tal como el primer día. 16 años del "fork" contra 9 del original. Eso dice algo sobre qué software sobrevive y por qué. Afortunadamente, no sobrevive solamente el que tiene más plata: sobrevive el que tiene a varios que no lo sueltan, lo cual es como para abrir tema acerca de la representabilidad de las minorías en Linux, y de por qué nunca va a pasar que las distros se fundan todas en el mismo gris corporativo. Por algo existe Void. Por algo existe Artix. Por algo no existe systemd en muchos de nuestros sistemas operativos. Por algo, justamente, no "porque sí", ni "por nada".

Yo uso Void Linux. Sin systemd, sin Wayland, sin telemetría, sin nada que no haya puesto yo. Y quería recordar la estética de KDE, no "instalar Plasma".
Y ahí fue que empezó el problema. Yo pensaba que era "compilar e instalar"...

El pedido que nadie atendió antes que Entropía.

Trinity está empaquetado para Debian. Para Ubuntu. Para Arch, Gentoo, Slackware, Fedora, openSUSE, Mageia, FreeBSD, OpenBSD, y hasta para DilOS, que es una distro de Solaris. ¿La conocías? Yo no: me enteré al empezar a caminar por los trillos de Trinity.

Para Void, no existe. O, bueno: no existía antes, ahora sí :D
Aunque... el pedido sí existe, y es el siguiente: issue #19243 de void-packages en https://github.com/void-linux/void-packages/issues/19243. Se llama "Package request: Trinity Desktop Environment" y fue abierto el 17 de febrero de 2020 por un usuario llamado "kasesag". Puso el enlace a la web de TDE, puso los PKGBUILD de Arch como referencia, y esperó.
Sigue abierto, sin asignar. Sin una sola rama, ni un solo pull request.
Seis años y medio: más o menos lo que lleva de vida el proyecto "Entropía binaria".
Y la situación no es que nadie lo haya intentado: hay un comentario en "Hacker News" de 2021 que dice, textualmente, que "hay un issue para empaquetar TDE para Void y aparentemente se puede compilar". Aparentemente. Alguien lo vichó, dijo "se puede", y... siguió con su vida. Casi como pasa conmigo después de 25 horas de trabajo.
El panorama tampoco es exclusivo de Void. Busqué y me encontré con un pedido equivalente en NixOS que también existe, también sigue abierto, y allí un usuario dejó escrita una frase más o menos como esta, que resume todo: "TDE es muy difícil de instalar en cualquier distribución no soportada".
Dijo "difícil"... Ahora sé exactamente cuánto.

Lo primero que descubrí: la documentación... no está en la documentación.

Empecé como empieza cualquiera: buscando la lista de dependencias.
El wiki oficial de TDE tiene una. Y al final de esa lista, escrito por los propios mantenedores, hay una nota que dice más o menos así: "Lista compilada a partir de viejos ebuilds de QT3/kdelibs/kde-base - ¿Alguien puede revisar esto, por favor?"
Ebuilds de Gentoo, de hace más de una década. Y los que mantienen el proyecto no saben si sigue siendo correcta.
Ahí entendí la primera lección de todo esto: en el software libre viejo, muchas veces la documentación real no está en la documentación, sino en los "empaquetados".
Si querés saber qué necesita TDE para compilar, no vayas a su Wiki, mirá el "debian/control" de Debian, que es exhaustivo porque tiene que serlo. Mirá el "PKGBUILD" de Arch, el "SlackBuild" de Slackware (que es el más cercano a compilar a mano porque Slackware no tiene un gestor que te resuelva el árbol de dependencias).
Esa información existe, está mantenida, y es correcta. Pero está escrita en el idioma de cada distro. Por ejemplo:

• libaspell-dev en Debian es aspell-devel en Void.
• libjpeg-turbo-dev es libjpeg-turbo-devel.

Y algunas no se traducen tan lindamente:

el header magic.h está en un paquete que Debian llama libmagic-dev y Void file-devel, porque el proyecto se llama "file" aunque la librería se llame libmagic.

Nadie hizo esa traducción para Void, y creo que ese fue todo mi trabajo, en el fondo: investigar, persistir, traducir, y orquestar, cosa que hago todo el tiempo.

El método (o de cómo tuve que proceder con "no adivinar").

Antes de escribir una sola línea de código, me senté a verificar. Solo quería "instalarlo y ya", no contribuír con otros con tanto tiempo invertido. No porque no sea mi estilo, sino porque pensé que iba a ser más sencillo. Bastante más sencillo.
Y la primera verificación, ya me alertó, a la vez que me salvó de un desastre.
La API de la Gitea oficial de TDE te da, para cada versión, una URL de descarga del tarball. Se llama "tarball_url". Está ahí, en el "Yéison" (JSON), "tranca palanca".
Esa URL retorna "404".
Lo que quiero decir, es que la API te publica una dirección de descarga que no funciona, a la vez que el servidor anuncia un archivo que no genera: si yo hubiera confiado en la documentación -que, insisto, es de la propia API del proyecto, nada menos- habría escrito un instalador que le explotaba en la jeta al primer usuario.
Lo mismo con el resto: cada vez que dí algo por sentado, perdí un montón de tiempo con...

• los nombres de los paquetes: busqué zlib-devel y lo primero que apareció fue lzlib-devel, que es otra cosa completamente distinta (el formato lzip). Si lo copiaba de memoria, mandaba a todo el mundo a instalar la librería equivocada. Y caí en eso, no te creas que fui una lumbrera;
• el SlackBuild de tqt usa un flag -platform linux-SB. Pasé rato tratando de entender qué era esa plataforma extraña, hasta que usando como fuente el script, averigüé: "cp -a linux-g++ linux-SB", lo cual es una copia de la plataforma estándar con 2 retoques. No existía tal cosa como "linux-SB";
• el repositorio se llamaba tqt3 y ahora se llama tqt: el paquete de macros de CMake figura en los "changelogs" como cmake-trinity, pero el repositorio se llama tde-cmake.

A cada una de estas cosas las descubrí corriendo comandos y mirando la salida, porque ninguna estaba escrita en ningún lado.
La regla que saqué de todo esto: verificá antes de escribir. Siempre. Aunque estés seguro... ¡Sobre todo si estás seguro!

La gotera.

Y entonces, empezó lo peor.
CMake tiene una fase de configuración: antes de compilar, busca lo que necesita y avisa si falta, y eso está muy bueno al compilar.
El problema es que CMake solo busca lo que los desarrolladores le dijeron que buscara: si un archivo ".cpp" perdido en "tdeui/" hace "#include <X11/Intrinsic.h>" y nadie declaró esa dependencia, CMake no tiene manera de saberlo... te enterás cuando el compilador llega a ese archivo y revienta. A los 2-4 minutos de compilación.

Así que mi ciclo era:

1. correr comandos para ver si se podían ir incluyendo en un procedimiento que yo ya estaba empezando a escribir en paralelo a mis pruebas directas en Void,
2. ver como se ejecutaban en la terminal y escribirlos realmente, para no olvidarlos,
3. esperar,
4. aguantar el reviente en el hocico,
5. buscar qué paquete de Void traía el "header" de lo que había causado la explosión,
6. instalarlo,
7. volver al punto 1.

Treinta y pico de veces, para:

• libudev.h
• ltdl.h
• magic.h
• X11/Intrinsic.h
• rpc/rpc.h
• XKBfile.h
• libxml-2.0
• libxslt
• glib-2.0
• alsa
• openssl

Y seguía, y seguía...
Hasta que mi primer momento de frustración llegó, y antes de abandonar (primera vez que lo pensaba) opté por llamar a Claude y le expliqué los problemas.
Le pregunté a Claude por qué carajo CMake no verificaba todo de una buena vez en lugar de ir para adelante como un zombi y fallar cada 3 minutos.
La respuesta me dejó pensando: es un bug de TDE, no de CMake.
Los CMakeLists.txt de Trinity, están incompletos: faltan declaraciones de dependencias que el código usa, y eso sucede cuando migrás un proyecto de 2001 de autotools (solo lo conocía de haberlo escuchado) a CMake, a lo largo de años, a mano, con poca gente. Es comprensible.
Y ahí está la trampa perfecta: la razón por la que este proceso es tan jodido es exactamente la razón por la que nadie lo había hecho para Void, todavía.
Es un trabajo ingrato: hay que aguantar decenas de revientes y anotar. Pero ojo, que este camino pedregoso no es exclusivo de Void, porque hay que pensar en que cuando un usuario de Debian instala TDE y le funciona a la primera, está cosechando el sufrimiento de alguien (o de algunos) que hizo esto mismo hace años y lo escribió en un debian/control.

Ese alguien, para Void, no existía.

Ah... y de paso: el sonido.
En medio del goteo, apareció "aRts". Yo ni siquiera sabía qué joraca era eso.
Ya no buscando en Internet, sino pidiéndole rigurosidad a Claude, me enteré de que "aRts" es el servidor de sonido de KDE 3: un daemon de 2001 que se mete entre las aplicaciones y la placa de audio. Y TDE lo demanda, porque viene activado por defecto.
Yo uso PulseAudio. Lo instalé yo, funciona, no lo voy a tocar.
Y además, 2 servidores de sonido peleándose por el mismo dispositivo es exactamente el tipo de quilombo que no le sirve a nadie.
Y acá tomé la típica decisión de director de batuta que define todo un proyecto: el escritorio se adapta al sistema, no al revés.

Volví a compilar por enésima vez (en esta oportunidad con la bandera -DWITH_ARTS=OFF) y... listo, a esperar otra vez.
TDE usa ALSA de manera directa, PulseAudio se pone encima como se pone encima de cualquier cosa que hable ALSA, y todo funciona. Sin daemon extra, sin conflictos, sin tocar una parte neurálgica del sistema por causa de un escritorio.

Después vino htdig, que es un indexador de búsqueda para el centro de ayuda de TDE. Última versión estable: 2004. Void ni lo empaqueta. Fuera (yo ya estaba en modo bolchevique de disciplina férrea a esta altura).

Después vino CUPS, y ahí me equivoqué feo. Mi primer instinto fue sacarlo y seguir, porque pensé: "¿para qué quiere CUPS un escritorio?". Pero un escritorio completo tiene su módulo de configuración de impresoras, y eso es parte de lo que hace que un escritorio sea un escritorio y no un gestor de ventanas con pretensiones. Instalar los headers no arranca ningún daemon, no toca nada, no consume nada. Solo deja la puerta abierta.

Pero aprendí, de nuevo.

Esta distinción me parece importante y es la que entendí que había que empezar a utilizar todo el tiempo: sacar la grasa que hace mal, pero no la que da sabor.

La tercera madrugada consecutiva, aquella en la cual casi tiro todo a la mierda.

Eran pasadas las 4 de la mañana: llevaba más de 23 o 24 horas laburando sobre lo mismo.
TDE compilaba (los módulos, que ya eran 6, uno tras otro), después de 30 y pico de dependencias descubiertas de a una, y algunas incluso con ayuda de Claude, que se esforzaba por buscar como perro sabueso pero que tampoco daba pie con bola. "starttde" estaba ahí, el binario existía, el escritorio arrancaba... pero era un auténtico desastre. Mirá por qué.

• Las ventanas no tenían barra de título, ni botones: podías cambiar entre ellas con [Alt] [Tab], pero no cerrarlas ni minimizarlas.
• Las aplicaciones abrían "vacías por dentro": el marco estaba, pero adentro no había botones, ni campos de texto. El espacio TDE se sentía como una casa abandonada.
• Konqueror, que ya de por sí posee limitaciones enormes, tiraba -literalmente- 20 carteles de error distintos antes de abrir, y abría "vacío".
• Firefox no arrancaba.

Escribí, textual, en mi guía de instalación (y esto marcaría mi segundo intento de "casi abandonar"): "Esto es un agujero negro que se chupa el 90% de todo lo que hago. Ya no estoy seguro de si vale la pena seguir. Está llevando demasiado recurso para ser tan solo un escritorio. La puta madre".

Y estaba por hacerlo. Tenía el mapa de reversión casi listo: 5 o 6 "rm -rf ALGO", y a otra cosa: era un "andá a cagar" sin dolor ni bronca.
Al otro día, con cabeza fresca pero habiendo dormido poco -otra vez- y mate de por medio, le di el extenso log a Claude en vez de seguir revisando yo. Y ahí saltó:
 

TWin: No window decoration plugin library was found. TWin will now exit

TWin -el gestor de ventanas de TDE- arrancaba, no encontraba ni un solo plugin de decoración, y se suicidaba. Por eso no había barras. Ni botones. Ni un carajo.
Pero el problema era que los plugins sí estaban. Los recordaba de una vieja época linuxera, y los había visto "cien veces" durante las "cien compilaciones": twin3_default.so, twin3_plastik.so, twin3_keramik.so, y así, quizás una veintena de ellos.

¡ Estaban en /opt/trinity/lib64/trinity/, pero TDE los buscaba en /opt/trinity/lib/trinity/ ! ¡Pero la reputa madre, carajo!

El symlink.

Acá está uno de los hallazgos más importantes, y esta es de las únicas cosas de todo este proyecto que no están documentadas en ningún lado.
En un sistema de 64 bits, CMake instala las librerías en lib64. Lo hace solo, aunque le pases -DLIB_SUFFIX="" para decirle que no (lo probé: te ignora olímpicamente y aún no sé bien por qué).
TDE, en cambio, busca sus plugins en "lib".
Por lo que averigüé, en /usr eso no se nota, porque casi todas las distros tienen un enlace simbólico de /usr/lib64 a /usr/lib. Está ahí desde hace años, es parte del paisaje, nadie lo mira.
En /opt/trinity no hay nada, porque es un prefijo nuevo, creado por el instalador. Y ese enlace no existe, salvo que lo crees vos, y sin él, TDE compila perfecto, instala perfecto, arranca... pero todo lo que dependa de cargar un plugin falla silenciosamente: las decoraciones de ventana, los estilos de los widgets (por eso era que las aplicaciones se veían vacías, los botones sin estilo, que había áreas que no se dibujaban). Y esto afectaba también a los ioslaves, que son los que manejan los protocolos. Por eso Konqueror no podía ni abrir siquiera una puta carpeta local.

20 carteles de error, 4 síntomas distintos, una sola causa.

ln -s /opt/trinity/lib64 /opt/trinity/lib

Lo corrí por recomendación de Claude, y las barras de título aparecieron en pantalla mientras miraba. Así, de una. Quedé como un pelotudo mirando la pantalla, pensando que esa era "otra cosa más que tampoco iba a funcionar".

Por lo que vi, todas las distribuciones que empaquetan a TDE resuelven esto en su "packaging", pero ninguna lo escribió en un lugar en donde se pueda encontrar: está enterrado en el pkg-plist de FreeBSD, en las reglas de Debian, en el PKGBUILD de Arch... Cada uno lo resolvió por su cuenta y siguió adelante.
Mi aporte en todo esto, no es haber compilado a TDE; yo para compilar necesito una pequeña receta. No vivo compilando. No soy el crack de esas lides. ¿Compilar?Vos, yo, cualquiera, con un poquito de paciencia y ganas, lo consigue.
Yo creo que encontré y escribí lo que hacía falta. Por eso es que lo expliqué en el "markdown" armado a las ligeras para CodeBerg. Por eso es que, de manera mucho más extensa, ahora mismo estoy escribiendo esto que estás leyendo.

Los permisos, la otra trampa.

Hubo un tercer problema, y lo cuento porque es igual de invisible.
Ya casi estaba entrando a quedar apenas aceptable el trabajo: ya no era una cagada, era algo apenas creíble. Y llegó otro mazazo que, al igual que los 2 garrones anteriores, no pudo quedarse contenido.
Trinity no aparecía en la pantalla de inicio de sesión. El archivo .desktop involucrado en esto, estaba bien (ya lo había validado con "desktop-file-validate"), los permisos eran idénticos a los de XFCE, todo estaba en el directorio correcto.
Pero no aparecía. Ni Claude estaba pudiendo con esto.
A la tercera vez que me hizo entrar a XFCE, hacer ajustes, cerrar sesión, ver si TDE aparecía como opción disponible... Dije... Che, si a esto no lo estoy pudiendo resolver ni siquiera con la ayuda del mejor LLM, quizás, en una pequeña párte, sea porque estoy estresado y pasado de rosca. Otra vez, a descansar, tarde, durmiendo poco, enfrascado con que "ya casi estaba en la orilla", "ya se veía tierra"... ¿firme?
A dormir, que había que laburar al otro día.
Finalizado el día de trabajo, vine directo con una idea en la sabiola:
¿por qué carajos no puede LightDM leer ese binario?
Llegu a casa, prendo la máquina, tiro un ls...

drwx------ 9 root root /opt/trinity

¿Por qué mierda "/opt/trinity" tenía permisos "700" indicando que solo root podía iniciar sesión gráfica, cosa totalmente estrambótica y mamotrética?
El binario, solamente por dentro, era perfectamente ejecutable... pero vivía en una casa tapiada.
¿De dónde salió ese 700?
Del umask de root cuando "make install" creó el directorio. ¿Quizás pase siempre y yo no haya sabido manejarlo? Sí o no, lo cierto es que esa era otra cosa que estaba hinchando las pelotas, anteponiendo otra roca de granito de 8500 toneladas entre el escritorio y yo. 

LightDM validaba el "TryExec", no podía manipular al archivo, y descartaba la entrada. Sin log, sin error, sin nada.

A la fuerza y a huevo, se me ocurrió correr desde XFCE un "chmod -R 755 /opt/trinity" pero tratándose un directorio con subdirectorios y archivos dentro, pensé... ¿y si estoy vulnerando la seguridad o haciendo cagada, solo intentando que esto funcione?
Ahí aprendí que en realidad, hubiera estado mal hacer el "chmod 755"... no lo sé, no lo probé a ver qué hubiera pasado.
La línea no era esa, sino este mamotreto: "chmod -R go+rX /opt/trinity".
El porqué de esa sintaxis ininteligible y contraintuitiva, es porque si intentáramos hacer esto usando mi "comando favorito" en una sola línea (chmod -R 755 directorio), romperíamos los permisos de todos los archivos contenidos en él. Al aplicarle 755 a todo (tipo tabla rasa), todos los archivos contenidos ganarían el bit de ejecución, y el sistema pasaría a verlos a todos ellos como a programas ejecutables, así fueran recetas de flan casero y de pucherito de gallina.
Por eso mismo es que se inventó el mamotreto "go+rX", porque es una forma directa en Linux de operar correctamente y a la misma vez sobre "carpetas y archivos" con una sola línea, sin bucles ni condicionales, tocando solo lo que debe ser tocado y nada más.
El "go" significa "grupos y otros" y el +rX significa "lectura y ejecución".
Y el por qué de la "X" mayúscula.....
Bué.........

Algo que yo tampoco sabía (y que no vi nunca, en ningún lado, hasta ahora), es que -y no sé si esto viene de UNIX o si es cagada de Linux) se decidió utilizar las mismas tres letras (r, w, x) también para las carpetas, pero cambiando ligeramente el significado.
En una carpeta, la x no significa "ejecutar", significa "entrar".
¿Qué pasa si tenés una carpeta SIN permiso "x"? Aunque seas el dueño, aunque tengas permiso de lectura y escritura, no vas a poder entrar a tu propia carpeta. Mirá la prueba que hice en su maldito momento (ya no podía creerlo, no terminaba más y me enfrentaba cada vez a cosas más raras):

[ entropia@user ] $ mkdir masequis
[ entropia@user ] $ touch masequis/contenido.txt
[ entropia@user ] $ echo "Hola" > masequis/contenido.txt 
[ entropia@user ] $ cat masequis/contenido.txt 
Hola
[ entropia@user ] $ chmod -x masequis/
[ entropia@user ] $ cat masequis/contenido.txt 
cat: masequis/contenido.txt: Permiso denegado

¿Te das cuenta de lo que estoy intentando mostrarte?
La X mayúscula sirve para tocar todas las carpetas y saltearse los archivos normales, y la x minúscula hace lo contrario: tocar todos los archivos y saltearse las carpetas.
Y a esto que  te estoy contando, ni siquiera sé si lo capté exactamente como correspondía, te soy honesto.

Volviendo... cerré sesión en XFCE por quintillonésima vez, y... ahí apareció el endemoniado TDE.

3 bichos (bugs), 4 días, y todos eran de esos que no se ven leyendo el código; se ven ejecutándolo.

El menú vacío.

Después de eso, TDE arrancó. Con barras, con estilos, con Firefox andando.
Ahora sí me volvía el alma al cuerpo.

Pero... no era "gratarola" este arranque prometedor. Otro hondazo en el medio de la jeta: el menú de aplicaciones estaba vacío, como si en mi Void no hubiera un puto programa instalado, siendo que los hay a montones.
El error -ya no recuerdo si en un cartel, en un log, o en el menú, te lo digo en serio-decía: "tde-applications.menu not found".
Con ayuda de Claude lo buscamos con lupa. No aparecía por ningún lado el soberano hijo de la madre.
A modo de intento tembloroso y timorato, fuimos al packaging de Debian, que a esa altura ya era una especie de oráculo de Delfos, y ahí estaba la respuesta en una sola línea de "debian/rules":

"install -p -D -m644 kded/tde-applications.menu → .../etc/xdg/menus/tde-applications.menu".

En Debian lo instalan "a mano"... ¿Sabés por qué? Porque el "make install" de tdelibs no lo instala. El archivo está en el código fuente, en "kded/", y ahí se queda.
Y hay un detalle más: al comando que reconstruye el caché de menús (tdebuildsycoca), lo busca en "/etc/xdg/menus/", ignorando la variable de entorno que le dice dónde mirar... Así que no alcanza con ponerlo en donde corresponde: hay que ponerlo en donde efectivamente busca.

Otra cosa que nadie escribió. Otra que ahora está escrita.

Sobre trabajar con una inteligencia artificial.

Quiero ser más honesto aún sobre qué hizo Claude y qué no, porque me parece importante al menos para mí dejarlo plasmado acá.

• Claude buscó bien, bajo parámetros de exigencia ultra estrictos.
• Encontró el "debian/control", el SlackBuild de tqt, el Makefile de FreeBSD. Tradujo nombres de paquetes entre distribuciones.
• Leyó y examinó varias veces varios volcados de terminal extensos y logs de cientos de líneas, indicando errores.

Lo que no hizo: decidir.

Las "185" decisiones que hacen que este TDE "sea mío", las tomé yo.

• Sacar aRts.
• Dejar CUPS.
• No tocar PulseAudio.
• Compilar la última versión en vez de "hardcodearla".
• Manejar todo como root en vez de subir y bajar privilegios todo el tiempo.
• Verificar antes de escribir en lugar de adivinar rápido.

Y hubo un momento, al principio, en donde tuve que frenarlo, porque estaba armando la lista de dependencias basándose en lo que yo ya tenía instalado en mi máquina, siendo que esto tenía que funcionar bien en cualquier Void, no solo en el mío. Esa corrección cambió el diseño entero, porque la hice sobre la marcha, dándome cuenta de lo difícil que iba a ser todo esto, y de que, si salía bien, Entropía iba a hacer, una vez más, historia. Ya no se trataba de instalar TDE para mí, para mostrarlo en un vivo de Entropía, sino que yo ya quería empezar a compartirlo. Y eso mismo fue lo que terminé haciendo.
Un "agente autónomo", sin nadie al lado, habría instalado aRts porque venía por defecto. Habría dejado htdig. Habría metido "359" paquetes sin preguntar. Y claro que habría devuelto un TDE funcional. Pero no este.
Le pregunté, mientras yo compilaba ya sin errores, si dentro de poco no iban a poder hacer todo esto solos. Su respuesta me pareció más lúcida de lo que esperaba: la mayor parte de estas 25 horas fueron compilando. A eso no lo acelera ni Peteco. Y el resto de ese tiempo, se fue buscando información que no existía.
Una máquina hubiera chocado contra los mismos callejones sin salida, los mismos tarballs rotos, el mismo "linux-SB" fantasma. Lo que sí se ahorraría es el ida y vuelta conmigo. Quizás la mitad del tiempo o más por "lentitud humana".
Pero un agente que pregunta por cada decisión no es más rápido: es esto mismo con otra cara. Y uno que no pregunta un sorongo te devuelve algo que no es tuyo, sobre lo cual tu autonomía es nula.
La división que funcionó fue esa: yo, como arquitecto en modo bolche, centralizar TODAS las decisiones, él BUSCAR y hacerlo BIEN.
Y todo escrito en BASH, sin una sola dependencia rara, en un lenguaje que cualquiera puede leer, auditar y modificar, que era -y es, siempre- el punto.

Lo que hay ahora.

Un script, en BASH como comenté, que compila TDE en Void Linux desde las fuentes oficiales, detecta automáticamente la última versión estable, y deja el escritorio andando en la pantalla de login.
En mi Ryzen 7 con 32 GB, tarda unos 10 minutos. En hardware modesto: bastante más (50-60 minutos).
Corrió completo en 2 máquinas físicas distintas (ningún virtualizar, ningún).
Está acá https://codeberg.org/entropiabinaria/TDE , y viene con una configuración de escritorio propia, que no es la de TDE por defecto, y esto también merece una explicación, porque no fue por capricho o por ego de mi parte.

El tema predefinido no es el estándar.

Este TDE recién compilado se mostró así: ventanas minimizadas que no aparecían en el panel, elementos del panel desparramados sin criterio (algunos a la izquierda, otros en el medio...), sin el reloj, y con el aspecto general "calco de Windows 2000". Horrendo.
No me pasé 25 horas peleando con esto para terminar mirando la pantalla de Redmond.
Así que configuré el escritorio lo mejor que pude, ya hasta salió bastante original la jugada. Y todo lo que hay en esa configuración es nativo de TDE: ni un ícono externo, ni un tema descargado, ni un fondo de pantalla bajado de Internet. Nada foráneo. Y si no te gusta, es un directorio con archivos de texto: borralo y tenés TDE crudo.

Lo que viene.

Estoy instalando 12 distribuciones que traen Trinity preconfigurado. Q4OS, Exe GNU, Dragora y varias más... Incluso Ubuntu TDE, ¡mirá lo profesional que me puse acá!
Y no es para "copiar estilos" nomás. Es porque esas distros resolvieron, cada una a su manera, el mismo problema con el que yo me encontré: TDE crudo no viene presentable. Alguien, en cada una de ellas, se sentó a decidir en dónde va el reloj y qué decoración de ventanas utilizar. Esas decisiones están ahí, en archivos de configuración, y nadie las documentó como decisiones.
Voy a hacerles ingeniería inversa y a armar un segundo script que te deje elegir: el estilo de Entropía binaria, o el de cualquiera de las otras. 12 opciones, de ser posible.

ACTUALIZACIÓN: a esto lo había escrito en el mismo momento en el cual TDE había levantado ya medianamente bien.
El proigrama de gestión de temas ya está hecho, y los temas no pudieron ser tantos, sino solo 6, por diversos motivos que explico en el mismo programa.
Si tenés instalado TDE, o si lo instalaste con este mismo script que estoy explicando lo más minuciosamente posible en este artículo, dale una vichada a este otro, el cual es su complemento ideal:
https://codeberg.org/entropiabinaria/tYb

Cierre.

Pasaron, hasta hoy, 6 años y medio de un pedido sin respuesta, y no porque esto fuera imposible, sino porque era un viaje de arena gruesa. O varios.
Hay una asimetría hermosa en todo esto...
25 horas mías (que al momento de retocar este script con cosas como la actualización en verde, de arriba, ya son casi el doble), 30 dependencias y pico, descubiertas de a una, a las 4 de la matina, alternando entre la laptop y la PC, y varios momentos en donde estuve seguro de que había que abandonar.
Y ahora, el script corre en diez minutos en una PC potente. Sin errores, te lo aseguro.
Esto es lo que es el software libre, en el fondo: alguien que se come el trabajo de fontanero de línea cloacal de ciudad una vez, para que los que vienen después no tengan que salir de la cañería con ese mismo olor a mierda. Yo me comí 25 horas de esto porque nadie lo había hecho para Void, pero también porque yo lo quería y porque pasó a ser una obligación moral en el medio del laburo. El próximo que quiera Trinity en Void va a correr un script y va a andar (o eso espero), y no va a tener la más pálida idea de nada de lo que acabo de contar. Y así debe ser, tal como yo mismo no tengo ni la más pálida idea de nada del esfuerzo de otros cuando uso sus programas: está perfecto que así sea, porque de esto se trata, de contribuir, y si es de corazón, mejor que mejor.
Un abrazo TDEro.