Sergio
af20d90648
`bzcmp`, `bzegrep`, `bzfgrep` y `bzless` son symlinks con **la ruta del SANDBOX horneada dentro**. El Makefile de bzip2 los crea con `ln -s $(PREFIX)/bin/bzdiff bzcmp` —con `$(PREFIX)` DENTRO del destino— y como bzip2 **no soporta `DESTDIR`**, la receta pasa `PREFIX=/out/usr` (el mismo truco que valkey) ⇒ el destino que queda es `/out/usr/bin/bzdiff`. Al hidratar, esos cuatro apuntan a un directorio que en el sistema real no existe. ⚠ **Cinco indicadores en verde sobre cuatro comandos que no funcionan**: el artefacto tiene contenido, `bzip2`/`bzgrep`/`bzdiff` corren, `static-audit` pasa, el grafo lo cuenta y la receta REPRODUCE. Ninguna métrica existente mira a dónde apunta un enlace. Arreglo: rehacerlos RELATIVOS después del install, que es lo correcto para un artefacto direccionado por hash — un enlace relativo sigue valiendo esté el árbol montado donde esté. Verificado: los cuatro resuelven y `bzip2 -c | bzcat` sigue dando `hola`. ## El guardián, en el mismo sitio y por la misma pregunta `--auditar-raices` ya contestaba «¿esta receta dejó ficheros donde no van?». Ahora contesta también la otra mitad: «¿dejó ENLACES a una raíz que no es del FHS?». Son la misma familia —un `install` que se equivocó de destino— y comparten la definición de `FHS_RAIZ`, que es lo que evita dos listas que se desincronizan. La regla es independiente del perfil, y por eso vale sobre el store entero: un enlace a OTRO artefacto es normal (`kinfocenter -> /usr/bin/systemsettings`, los dos en `escritorio-kde`, resuelve en el rootfs fundido). Lo que nunca puede estar bien es un destino absoluto cuya primera componente no sea del FHS: `/out`, `/src`, `/tmp` son rutas del lab. Dos correcciones al propio guardián, las dos aprendidas midiendo: · **Sólo audita el artefacto VIGENTE de cada receta.** El store guarda todos los sellados históricos, así que la primera versión acusaba a bzip2 por el artefacto YA SUPERADO — el mismo sobre-reporte que `static-audit.sh` tuvo que quitarse de encima. El hash vigente sale de los grafos de estado, no de 1150 llamadas a `takana hash`. ⚠ Y hay que regenerar **los cinco** grafos: con sólo el principal regenerado, el de KDE seguía apuntando al bzip2 viejo y el filtro lo dejaba pasar. · **Un barrido que no miró NADA lo dice y sale 2.** Filtrar por hash vigente hace que un `--store` que no case con los grafos deje cero artefactos auditados, y sin la guarda eso se imprimía como «✓ 0 ofensores»: una respuesta falsa con forma de respuesta. Probado: `--store /tmp` → exit 2. El control del hallazgo es el propio arreglo, sobre datos reales y no sintéticos: antes del fix el barrido nombra los cuatro enlaces de bzip2; después, `✓ ninguno`.
54 lines
2.8 KiB
TOML
54 lines
2.8 KiB
TOML
# bzip2 1.0.8 → libbz2.a (C, Makefile custom sin configure). Lib base: compresión .bz2, cola C.
|
|
# De-Alpinizada: compiler=zig-cc (migrado de gcc, matar-gcc 2026-07-16), make directo, install con PREFIX (el Makefile no usa DESTDIR).
|
|
name = "bzip2"
|
|
version = "1.0.8"
|
|
license = "bzip2-1.0.6"
|
|
[source]
|
|
tarball = "https://sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz"
|
|
sha256 = "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
|
|
# Split de la info de depuración (SDD 23 etapa 4, tanda de HOJAS). Entra en `hash_inputs`.
|
|
strip_debug = true
|
|
flags = []
|
|
[deps]
|
|
build = ["binutils", "make"]
|
|
|
|
[build.phases]
|
|
# CC="$CC" explícito: el Makefile de bzip2 HARDCODEA `CC=gcc` en su cabecera, así que un `make` a
|
|
# secas usa el gcc de Alpine aunque la receta declare compiler=zig-cc. Esta receta decía "migrado a
|
|
# zig-cc (matar-gcc 2026-07-16)" y seguía pasando `CC=gcc`: la migración fue COSMÉTICA — cambió el
|
|
# campo, no el build. El frente contaba `compiler = "gcc"` y no veía la fase (2026-07-17).
|
|
# LDFLAGS explícito: el `-static` que takana exporta por `link = "static"` se pierde al no pasarlo
|
|
# al make de un Makefile custom ⇒ el binario salía dinámico. Medido con scripts/static-audit.sh.
|
|
# OJO: `-static`, NO `-all-static`. `-all-static` es un flag de LIBTOOL (el patrón de
|
|
# jq/parted/shadow/procps-ng, que sí linkean con libtool); bzip2 usa Makefile crudo, así que el
|
|
# flag llega tal cual al compilador → "error: Unknown Clang option: '-all-static'".
|
|
compile = 'make CC="$CC" LDFLAGS="-static -no-pie"'
|
|
# ⚠ **LOS CUATRO SYMLINKS SALEN ROTOS SI NO SE REHACEN, Y EL ARTEFACTO NO LO DICE.** El `install`
|
|
# del Makefile de bzip2 los crea así:
|
|
#
|
|
# cd $(PREFIX)/bin; ln -s -f $(PREFIX)/bin/bzdiff bzcmp
|
|
#
|
|
# — con `$(PREFIX)` DENTRO del destino. Como bzip2 **no soporta `DESTDIR`** (por eso acá va
|
|
# `PREFIX=/out/usr`, el mismo truco que valkey), el destino que queda horneado es
|
|
# `/out/usr/bin/bzdiff`: la ruta del SANDBOX. Al hidratar, `/usr/bin/bzcmp` apunta a un `/out` que no
|
|
# existe en el sistema real ⇒ `bzcmp`, `bzegrep`, `bzfgrep` y `bzless` no funcionan.
|
|
#
|
|
# Nada lo delata: el artefacto tiene contenido, `bzip2` y `bzgrep` corren, el audit de enlace
|
|
# estático pasa y la receta REPRODUCE. Se ve buscando en el store symlinks que no resuelven dentro de
|
|
# su propio artefacto (2026-09-12; los únicos dos casos del corpus eran éste y uno legítimo de KDE,
|
|
# que apunta a otro artefacto del MISMO perfil).
|
|
#
|
|
# Se rehacen RELATIVOS, que es lo correcto para un artefacto direccionado por hash: un enlace
|
|
# relativo sigue valiendo esté el árbol montado donde esté.
|
|
install = '''
|
|
make install PREFIX=/out/usr CC="$CC"
|
|
for par in bzcmp:bzdiff bzegrep:bzgrep bzfgrep:bzgrep bzless:bzmore; do
|
|
ln -sf "${par#*:}" "/out/usr/bin/${par%%:*}"
|
|
done
|
|
'''
|