La gestión de paquetes es donde un sistema respeta tu tiempo o te lo roba en silencio. Dos decisiones suelen tomarse juntas y conviene separarlas: qué hace el gestor de paquetes cuando una transacción falla, y cuándo pagas el cambio. 0dyssey se está construyendo sobre xbps y una base Void de actualización continua. Las dos mitades de ese razonamiento se generalizan más allá de cualquiera de las dos elecciones.
La primera prueba: qué pasa a medias
El momento interesante de un gestor de paquetes no es la instalación que sale bien. Es la que muere a la mitad: una conexión que se cae, un disco lleno, un Ctrl-C en el peor segundo, un corte de luz durante una actualización.
Un gestor de paquetes supera esa prueba cuando la interrupción te deja exactamente donde estabas, con una base de datos que sigue describiendo el sistema que realmente tienes. La suspende cuando te deja en algún punto intermedio, con media transacción aplicada y una base de datos que ahora describe una máquina que no existe. El procedimiento de recuperación del segundo caso es folclore, y el folclore no escala a un sistema que usan otras personas.
xbps aplica las instalaciones y eliminaciones como transacciones: se completan o se revierten. Esa única propiedad es la razón por la que está en la pila. También es rápido, porque el formato de paquete y el resolutor de dependencias se diseñaron juntos en lugar de añadirse sobre una década de compatibilidad hacia atrás, pero la velocidad es un extra y la atomicidad no lo es.
# sincronizar el índice remoto y luego actualizar el sistema en una sola transacción
$ sudo xbps-install -Su
# buscar en los repositorios remotos antes de instalar nada
$ xbps-query -Rs compositor
# eliminar los paquetes de los que ya no depende nada
$ sudo xbps-remove -o
# verificar la base de datos de paquetes contra lo que realmente hay en disco
$ xbps-pkgdb -aLos dos últimos comandos delatan la intención. La limpieza de huérfanos y la comprobación de integridad de la base de datos no son funciones que nadie ponga en una página de inicio. Existen porque quienes construyeron la herramienta usan lo que construyeron, y en algún momento quisieron preguntarle al sistema si seguía coincidiendo con sus propios registros.
La segunda prueba: cuándo pagas el cambio
Todo sistema paga el cambio. La única pregunta es si lo paga de forma continua o de golpe.
Las versiones puntuales parecen seguras. Congelas una instantánea, la publicas y te dices que has reducido el riesgo. Lo que has hecho en realidad es aplazarlo, y luego pagarlo todo de una vez en una migración gigante de cambio de versión que toca todo a la vez.
Una base congelada es realmente la respuesta correcta para una flota que no debe moverse: un sistema dentro de un perímetro de certificación, o cuya carga de trabajo está validada contra un conjunto exacto de versiones. Es un requisito real y la actualización continua sería la respuesta equivocada. Quien te diga lo contrario no ha tenido que firmar los papeles.
Es la respuesta equivocada para un sistema cuyo trabajo es mantenerse al día con el hardware y las cadenas de herramientas que tiene debajo. Una base de actualización continua integra el cambio como un flujo contra el que puedes probar de forma permanente, en lugar de un precipicio del que te lanzas cada dos años. Combinada con instalaciones transaccionales, la unidad de riesgo pasa a ser un paquete en un momento dado, un tamaño sobre el que una persona puede razonar de verdad.
Lo que cuesta la actualización continua, sin rodeos
- La actualización continua exige disciplina a quien mantiene el sistema. Las actualizaciones que llegan a los usuarios hay que probarlas antes, y esa carga nunca termina.
- No hay un número de versión contra el que certificar, lo que es un bloqueo real en los entornos que exigen uno.
- «Ayer funcionaba» deja de ser un informe de error útil, así que hay que poder decir con precisión qué cambió y volver a dejarlo como estaba.
El tercer punto es lo que une las dos decisiones. Un modelo de actualización continua solo es defendible sobre un gestor de paquetes que revierte limpiamente. Elige uno sin el otro y habrás asumido el coste de ambos: cambio continuo sin posibilidad de deshacer.
El compromiso, y sus límites
0dyssey se está construyendo para heredar xbps y una base de actualización continua de Void, con su propia capa de experiencia de usuario por encima en lugar de un fork de lo que hay debajo. Esa capa es la parte de la que somos responsables, y el compromiso que estamos dispuestos a asumir en público es un criterio más que una promesa de velocidad: una operación de paquetes debe ser una transacción, y una actualización debe poder deshacerse.
Todavía no hay una versión que instalar, así que nada de esto es un benchmark ni el informe de una máquina en funcionamiento. Es la decisión, escrita mientras aún es barato discutirla, y está escrita como criterio a propósito. Si aparece un modelo de paquetes mejor que supere las dos pruebas, el criterio sobrevive y la elección que hay debajo puede cambiar.