SergioandClaude Opus 5
466972e301
Cuatro artefactos sellados y el paso 2 del plan cerrado. Los diez applets que dejan de depender de busybox salieron de arreglar recetas, no de escribir código: xz unxz xzcat lzma unlzma lzcat → recipes/xz-tools.toml (nueva, b3:194c7d69…) vi → un symlink en recipes/vim.toml cpio → un symlink en recipes/libarchive.toml arch hostname → los trajo el feature de uutils (b3:614ff653…) xz-tools es el TERCER caso de la familia de zstd-cli, y eso ya estaba escrito en targets.toml: «la receta canónica construye sólo lib/ y su artefacto no tiene usr/bin; declararla no habría arreglado nada». Igual que musl-shared, zlib-shared y libffi-shared. Cuatro veces la misma forma — la receta publica la lib, la imagen declara el paquete, y el binario no está. Va como variante porque ampliar la canónica re-hashearía a sus 14 consumidores. ⚠ xz-tools selló DINÁMICO en la primera corrida pese al link = "static", y funcionaba: comprimía y descomprimía sin una queja. Es el relink de libtool, que libarchive.toml y bluez.toml ya documentan — hace falta LDFLAGS=-all-static en compile Y en install. Lo delató el `file` del binario, no una prueba que fallara. Paso 2 del plan: uutils, findutils, findutils-xargs, diffutils, gzip, grep y xz-tools declarados en el perfil `base` — seis recetas que llevaban meses `sealed` con `perfiles: []`. Hasta hoy, `find`, `xargs`, `diff`, `cmp`, `gzip`, `zcat` y `grep` en una imagen de takana eran el applet de busybox, no porque faltara escribirlos sino porque nadie los declaró. `grep` entra como PUENTE declarado: ripgrep ya viaja pero publica `rg` y no es grep POSIX. El censo gana modo --guardian, y vigila PÉRDIDAS, no un umbral: un umbral hay que subirlo cada vez que se retira un applet y a la tercera nadie lo sube con criterio; que un applet con proveedor medido deje de tenerlo es siempre una regresión. Probado en los dos sentidos — rc=0 contra /store, rc=1 contra un store mutilado, nombrando applet y proveedor perdido. Los cuatro sellaron con el mismo hash en el store tirable y en /store: dos work_root distintos, bytes idénticos. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
64 lines
3.9 KiB
TOML
64 lines
3.9 KiB
TOML
# xz 5.8.3 — VARIANTE que construye las HERRAMIENTAS de línea de comandos. NO sustituye a
|
|
# `recipes/xz.toml`.
|
|
#
|
|
# ── POR QUÉ EXISTE ──────────────────────────────────────────────────────────────────────────────
|
|
# La canónica pasa `--disable-xz --disable-xzdec --disable-lzmadec --disable-lzmainfo
|
|
# --disable-scripts`: es liblzma y NADA más, a propósito, porque de ella cuelgan 14 recetas que la
|
|
# enlazan. El problema es que `xz` figura en SEIS perfiles y su artefacto tiene el `usr/bin` VACÍO,
|
|
# así que **el único `xz` dentro de la imagen es el applet de busybox** — medido el 2026-09-21 con
|
|
# `scripts/busybox-censo-proveedores.py`, y es de los seis applets que hoy nadie más provee
|
|
# (`xz unxz xzcat lzma unlzma lzcat`). Ver `docs/plan-botar-busybox.md`, §censo de proveedores.
|
|
#
|
|
# ── POR QUÉ VARIANTE Y NO QUITARLE EL `--disable-xz` A LA CANÓNICA ──────────────────────────────
|
|
# Tocar `[build.phases] configure` de `xz.toml` re-hashea el artefacto y con él las 14 recetas que
|
|
# lo declaran dep (`appstream dwarves ripgrep-all swayimg maturin wasm-pack trunk fnm dprint dufs
|
|
# cargo-deb adwaita-hello sourceview-hello hammer-edit`). El coste no lo paga la funcionalidad que
|
|
# se gana. Mismo patrón que `elfutils-libdw` sobre `elfutils` y que `openssl-threads`.
|
|
#
|
|
# ── LO QUE INSTALA, Y LO QUE SE BORRA A PROPÓSITO ───────────────────────────────────────────────
|
|
# Sólo `usr/bin` + sus manpages. La lib y los headers se RETIRAN del artefacto aunque el `make
|
|
# install` los genere: si viajaran, al hidratar una imagen que ya lleva `xz` habría dos `liblzma.a`
|
|
# y dos `lzma.h` disputándose la misma ruta, y quién gana lo decide el orden de hidratación — que
|
|
# es exactamente la clase de cosa que no debe depender del orden. La lib la sigue publicando la
|
|
# canónica, que es su dueña.
|
|
|
|
name = "xz-tools"
|
|
version = "5.8.3"
|
|
license = "0BSD"
|
|
|
|
[source]
|
|
# Mismo tarball y mismo sha256 que la canónica: es el mismo upstream con otro `configure`.
|
|
tarball = "https://github.com/tukaani-project/xz/releases/download/v5.8.3/xz-5.8.3.tar.xz"
|
|
sha256 = "fff1ffcf2b0da84d308a14de513a1aa23d4e9aa3464d17e64b9714bfdd0bbfb6"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
flags = []
|
|
|
|
[deps]
|
|
build = ["make"]
|
|
|
|
[build.phases]
|
|
# Las herramientas vienen habilitadas por defecto; lo que se apaga es lo de siempre (shared, doc) y
|
|
# `--disable-nls`, que en musl evita el <libintl.h> que no existe. `--enable-small` NO: cambia el
|
|
# rendimiento del descompresor y esto es la herramienta de uso general, no un initramfs.
|
|
configure = '''
|
|
./configure --build=$CBUILD --host=$CHOST --prefix=/usr \
|
|
--disable-shared --enable-static --disable-nls --disable-doc
|
|
'''
|
|
# ⚠ `LDFLAGS=-all-static` EN COMPILE **Y** EN INSTALL. xz enlaza con libtool, y libtool RELINKEA
|
|
# al instalar: sin el flag en las dos fases el `link = "static"` de la receta se ignora **en
|
|
# silencio** y los binarios salen dinámicos. Medido acá: la primera corrida selló un `xz` que
|
|
# funcionaba (comprime y descomprime) y era `interpreter /lib/ld-musl-x86_64.so.1`. Mismo pisón que
|
|
# ya documentan `recipes/libarchive.toml` y `recipes/bluez.toml`; lo verifica `scripts/static-audit.sh`.
|
|
compile = 'make LDFLAGS=-all-static'
|
|
# `install` completo y después se retiran lib/include/pkgconfig: es más robusto que un
|
|
# `make -C src/xz install`, que se saltaría `xzdec`, `lzmainfo` y los scripts (`xzgrep`, `xzdiff`,
|
|
# `xzless`, `xzmore`) — que son los que dan `lzcat`/`unlzma`/`unxz` por symlink.
|
|
install = '''
|
|
make LDFLAGS=-all-static DESTDIR=/out install
|
|
rm -rf /out/usr/lib /out/usr/include /out/usr/share/doc
|
|
'''
|