Resumen/xpm — gestor de paquetes

xpm — Notas de integración futura

Cómo se espera que xpm vuelva a entrar en el flujo de la distribución X, las condiciones previas antes de que pueda ser el camino de instalación activo y los contratos (seams) que deberían permanecer estables mientras tanto. Este documento registra la comprensión actual tomada del ROADMAP a nivel de workspace, del README/ROADMAP de este repo y de docs/INTEGRATION.md. Nada de esto es trabajo commiteado; es contexto de planificación.

Dónde está xpm hoy

Dentro de la iniciativa reboot, el tooling xpm/xpkg está pospuesto (ROADMAP del workspace, Fase 4). El payload de la distro se empaqueta hoy con un flujo de PKGBUILD + makepkg como el paquete x-scripts y se publica a través del repositorio compatible con pacman, consumido en los sistemas instalados con pacman. xpm es una base de código Rust funcional y bien testeada que todavía no está conectada al camino activo del reboot.

La consecuencia honesta: la documentación del comportamiento de cara al usuario puede desviarse de lo que la distro entrega hoy, porque la distro entrega el camino pacman, no xpm. Trata las funciones de xpm como el camino nativo futuro salvo que el flujo reboot las adopte.

Lo que ya añadió la alineación con generaciones

En la rama feat/generations-alignment aterrizó un avance autocontenido sin conectar el resolver:

• journal de transacciones (/var/lib/xpm/journal/*.json) y xpm history [--json];
• hooks pre-transaction.d/post-transaction.d con el contrato de entorno XPM_* (runner implementado; los scripts de hook llegan con x-scripts);
• seguimiento de razón de instalación y filtros (xpm query --format tsv, --explicit/--deps);
• metadatos reason/origin/files en la base de datos local, y xpm files/xpm info reales (estos dos habilitan x gen restore --pkg en sistemas xpm).

Siguen pendientes del mismo diseño: el resolver conectado al CLI, --orphans, xpm rollback --last y xpm diff <generación>.

Cuándo podría volver xpm a estar activo

Razones que traerían a xpm (y a su compañero xpkg) de vuelta al alcance, según el ROADMAP del workspace:

• La distro necesita el repositorio .xp nativo como canal de distribución (dejar de consumir el layout pacman para los paquetes x).
• El camino de instalación nativo ya es funcional (install con resolver para nombres de repo y archivos .xp locales, upgrade con cierre de dependencias, base .files); quedan rollback/diff y el despliegue del repositorio .xp nativo.
• El empaquetado reproducible y con lint (xpkg) con firmas OpenPGP se convierte en un requisito duro del pipeline de payload.

Hasta entonces, xpm no debe tratarse como dependencia del build de la distro, y el flujo reboot no debe añadir suposiciones sobre xpm instalado.

Condiciones previas antes de que xpm sea el camino activo

Huecos a nivel de código que deben resolverse cuando la herramienta se reactive (honesto, del propio roadmap del repo y del main.rs actual):

1. Implementar rollback y diffs de generaciones. install (repo o .xp local) y upgrade con cierre de dependencias ya usan el resolver; quedan rollback --last, diff <generation> y enlazar las entradas del journal con ids de generación.
2. Completar el endurecimiento de transacciones. Gestión de .pacnew/.pacsave, ejecución de alpm-hooks más allá de los scriptlets de .INSTALL, y tests de conflictos/rollback.
3. Completar el endurecimiento y la recuperación de transacciones. El journal de transacciones y los hooks pre/post-transaction.d están implementados; siguen abiertos xpm rollback --last, enlazar las entradas de history con ids de generación, la gestión de .pacnew/.pacsave, la resolución de conflictos y los tests de rollback.
4. Cerrar los hitos de preparación para producción (Fase 8 y Fase 9 del ROADMAP del repo): benchmarks frente a pacman, stress testing contra un repositorio completo, fuzzing, auditoría de manejo de errores (descargas parciales, paquetes corruptos, disco lleno) y objetivos post-v1.0 (bindings de Python, i18n, TUI, selección inteligente de mirrors, caché configurable).
5. Reconciliar inconsistencias de configuración como el default del keyring GPG (config.rs usa /etc/pacman.d/gnupg/ mientras que la guía del README usa /etc/xpm/gnupg/).

Integración con xpkg

xpm y xpkg son binarios complementarios que comparten el formato de paquete (según docs/INTEGRATION.md):

Ciclo de vida: receta de fuente (XBUILD/PKGBUILD) -> xpkg build -> paquete .xp -> base de datos de repositorio -> hosting estático -> xpm sync -> xpm install/upgrade (verificar firma, extraer, ejecutar scriptlets de .INSTALL, registrar en local). xpkg también puede emitir una base de datos estilo ALPM estándar; xpm lee tanto los campos estándar como los extendidos de xpkg (FILENAME, SHA256SUM, URL), manteniendo compatibilidad con los repositorios de Arch.

El README del repo remite a docs/INTEGRATION.md para ver cómo trabajan juntas las herramientas; mantén ese documento en sync cada vez que el formato cambie.

Contratos (seams) que deberían permanecer estables

Como xpm puede estar inactivo durante un tiempo, estas interfaces deben tratarse como superficies de compatibilidad y documentarse con cuidado cuando cambien:

• Formato de paquete: .xp == estructura ALPM .pkg.tar.zst (tar.zst con .PKGINFO, .BUILDINFO, .MTREE y .INSTALL opcional). La versión de formato es implícita en la estructura del .PKGINFO; ambas herramientas deben moverse en lockstep.
• Layout de repositorio: endpoint de sync <server>/<repo>.db (+ .files), árbol nativo xpm en https://equislinux.github.io/x-repo/x/$arch (no confundir con el endpoint pacman bajo /repo/x86_64), firmas como .sig separadas, keyring como trustedkeys.gpg.
• Configuración: /etc/xpm.conf (TOML), repos de usuario en /etc/xpm.d/, variables de URL $repo/$arch, semántica de sig_level.
• Layout de la base de datos local: /var/lib/xpm/local/<pkg>/ con entradas version y files, DBs de sync bajo /var/lib/xpm/sync/.
• Contrato de scriptlets: funciones bash ejecutadas desde .INSTALL con las variables de entorno XPM_ROOT_DIR, XPM_PKG_NAME y XPM_PKG_VERSION.

Convenciones de trabajo aplicables también en el futuro

Cuando se retome el trabajo en xpm, se aplican las convenciones del workspace igual que hoy: el trabajo se hace en la rama x/reboot de este repo, los commits quedan locales (sin push), los mensajes de commit no llevan emojis ni referencias a asistentes, y cada fase cierra con tests locales antes de seguir. Registra cualquier decisión de integración en el repo o carpeta al que pertenezca.

Véase también

• Roadmap del repo: ../../ROADMAP.md
• Roadmap a nivel de workspace (fases del reboot, incluida la fase pospuesta de tooling): ../../../ROADMAP.md
• Integración xpm/xpkg: ../INTEGRATION.md
• Arquitectura del resolver: ../RESOLVER.md

Editar esta página en GitHub