Resumen/x-repo — repositorio de paquetes
Publicar un paquete
Publicar en el repositorio [x] de pacman es un flujo de build local y luego
commit. GitHub Actions nunca construye paquetes; solo despliega lo que está
commiteado bajo public/ (ver web-portal.md).
El ciclo completo: build local -> repo-add (+ firma opcional) -> SHA256SUMS
-> PR -> deploy en Pages.
1. Build local
Requisitos: un entorno tipo Arch con makepkg y repo-add disponibles.
Paquete construido desde un PKGBUILD de este repo
Trabaja sobre la fuente del paquete y luego constrúyelo dentro de su directorio
exactamente como hace build-packages.sh:
cd packages/x-release # o packages/x-dev
makepkg -cf --noconfirm
Esto produce un .pkg.tar.zst (p. ej. x-release-1.0-8-any.pkg.tar.zst) dentro del
directorio del paquete.
Paquete externo (x-scripts)
x-scripts se construye en el repo hermano scripts (su PKGBUILD vive en
scripts/packaging/), no aquí, y lleva el snapshot offline del escritorio equisdots
que usa el instalador. Constrúyelo allí:
cd scripts/packaging && makepkg -f
build-packages.sh importa automáticamente el
../scripts/packaging/x-scripts-*.pkg.tar.zst resultante y lo elimina del directorio
de build. También puedes colocar el tarball directamente en
public/repo/x86_64/ antes de ejecutar el script. No existe un directorio de fuente
packages/x-scripts/ en este repo.
Paquetes nativos .xp (vía xpm/xpkg)
El endpoint .xp bajo public/x/x86_64/ queda fuera del alcance de este flujo: el
workflow nativo automatizado está desactivado y se conserva como referencia en
docs/build-x-native-workflow.md.
2. Regenerar el repositorio (repo-add)
Desde la raíz del repositorio ejecuta:
./build-packages.sh # construye x-release/x-dev + importa x-scripts + indexa
./build-packages.sh --index-only # omite los builds locales (solo importa/indexa)
El script:
-
Reconstruye los paquetes PKGBUILD configurados (
x-release,x-dev) conmakepkgsalvo con--index-only. -
Importa
../scripts/packaging/x-scripts-*.pkg.tar.zstcuando existe y copia los tarballs recién construidos dex-release/x-devapublic/repo/x86_64/, borrando solo esos artefactos de build. Los binarios commiteados bajopackages/xpm,packages/xpkg,packages/xfetchypackages/xtopno se tocan. -
Reconstruye la base de datos de pacman desde cero a partir de todos los tarballs del directorio (esto también elimina entradas de paquetes que ya no existen):
repo-add -R x.db.tar.gz *.pkg.tar.zst cp x.db.tar.gz x.db cp x.files.tar.gz x.files sha256sum * > SHA256SUMSCuando
X_REPO_SIGN_KEYestá definida,repo-addcorre con-s -k,SHA256SUMSse firma y el keyring se re-exporta; ver Firmar el repositorio.
No edites x.db ni SHA256SUMS a mano; regenéralos siempre con este script (las
reglas de contribución en CONTRIBUTING.md también prohíben ediciones manuales de la
base de datos).
3. Revisar y commitear
Comprueba qué cambió bajo public/repo/x86_64/:
git status
git diff --stat
Cambios esperados para una actualización de paquete:
- el nuevo
.pkg.tar.zst(y la eliminación de la versión reemplazada), x.db,x.db.tar.gz,x.files,x.files.tar.gzregenerados,SHA256SUMSregenerado,- el propio cambio del
PKGBUILDbajopackages/.
En builds firmados, cuenta además con las firmas detached de los ficheros que cambian:
*.pkg.tar.zst.sigpor cada paquete (re)firmado,x.db.sig/x.db.tar.gz.sigyx.files.sig/x.files.tar.gz.sig,SHA256SUMS.sig,signing.pubytrustedkeys.gpgcuando cambie el material del keyring.
Commitea los cambios del repositorio, por ejemplo:
git add packages/x-release public/repo/x86_64
git commit -m "publish x-release 1.0-8"
4. Pull request
Según CONTRIBUTING.md, el flujo de contribución es fork, rama y pull request contra
la rama main. Los mantenedores también pueden commitear a una rama de trabajo y abrir
el PR directamente. Fusiona a main cuando pase la validación.
5. Desplegar en GitHub Pages
Cuando los cambios estén en main, despliega el sitio para que los archivos nuevos del
repo salgan en producción:
- Ve a la pestaña Actions de
equislinux/x-repo. - Ejecuta manualmente el workflow "Deploy Website to GitHub Pages" (
build.yml) medianteworkflow_dispatch. - El workflow ejecuta
npm ci && npm run build(export estático del sitio Next.js incluido todo lo depublic/), comprueba que existanx.dby un tarball dex-release, y sube./outa GitHub Pages.
Los paquetes actualizados quedan servidos en:
https://equislinux.github.io/x-repo/repo/x86_64/(repo[x]de pacman)
Advertencias
- No ejecutes dos workflows de deploy de Pages a la vez; se sobrescribirían el
despliegue mutuamente (en
build.ymlhay un grupo de concurrenciapages, ydocs/build-x-native-workflow.mdavisa de lo mismo para el workflow nativo, que está desactivado). - Mantén el repositorio sincronizado con sus consumidores:
x-releaseyx-devse instalan desde este repo durante la instalación de la distro X, yx-scriptsdebe coincidir con la revisión del payload que espera el instalador.
Firmar el repositorio (X_REPO_SIGN_KEY)
La firma es opcional y se controla con una única variable de entorno,
X_REPO_SIGN_KEY (el fingerprint o key ID de la clave de proyecto). El
repositorio está firmado hoy en la rama feat/signing (incluido
x-scripts 0.1.0-19), mientras que el ISO sigue configurando [x] como
Optional, así que la verificación todavía no se exige.
Con la variable exportada, build-packages.sh:
- firma cada tarball de paquete — los construidos localmente vía
makepkg --sign --key "$X_REPO_SIGN_KEY"y el importado dex-scriptscongpg --detach-sign—, produciendo un.pkg.tar.zst.sigdetached por paquete; - ejecuta
repo-add -s -k "$X_REPO_SIGN_KEY", con lo quex.db/x.filesquedan firmados, y espejax.db.sig/x.files.sigdesde las firmas de los.tar.gz; - firma
SHA256SUMS, produciendoSHA256SUMS.sig; - exporta el keyring público como
trustedkeys.gpgysigning.pubenpublic/repo/x86_64/.
Sin X_REPO_SIGN_KEY el script sigue publicando el repositorio sin firmar
y avisa. Commitea los ficheros de firma y el keyring regenerados junto a la
base de datos y los tarballs.
El procedimiento completo (creación de la clave, configuración de
SigLevel/pacman-key en el consumidor, integración pendiente en el ISO y
rotación de clave) está en signing.md.