Tres arreglos que son el mismo: un campo que nadie lee es un campo que miente.
1. yupana._deps() leía SÓLO `deps.build`. Como yupana es la base de todas las
herramientas de grafo, una dep de EJECUCIÓN no existía para ninguna: ni el
vigía de sonames, ni la membresía de perfiles, ni el rootfs hidratado.
Medido: firefox declaraba `runtime = ["gcc-libs"]` y el cierre de las cuatro
imágenes seguía sin libstdc++.so.6, así que el navegador no arrancaba y el
vigía lo seguía reportando como hueco DESPUÉS de haberlo arreglado.
`deps.runtime` está en el esquema de hammer desde siempre. La unión es la
definición de cierre: para CORRER hacen falta las dos.
2. build-state.py, lo mismo y por lo mismo.
3. El vigía entra en el LATIDO y deja docs/state/sonames.txt. Existía desde
antes y contesta la pregunta que el grafo no contesta —no «¿está sellado?»
sino «¿arranca?»— pero NADIE LO CORRÍA: no estaba en cosecha-cron y no dejaba
fichero de estado. Por eso libstdc++.so.6, que rompía el navegador en los
CUATRO perfiles, estuvo en su salida sin que nadie lo leyera, y se
redescubrió arrancando atuq a mano. Un vigía que hay que acordarse de invocar
no se distingue de no tenerlo.
Y se BORRA scripts/audit-needed.sh, que escribí ayer sin ver que vigia-sonames.py
ya hacía exactamente esto, con la misma frase en la cabecera. Dos herramientas
que miden lo mismo divergen y la que nadie mira es la que miente; la que se
queda es la que ya existía, que además reporta POR PERFIL y encontró más cosas.
python3 declara sus cuatro deps de ejecución (readline/sqlite/lzma/bz2): son
módulos de la stdlib que se cargan por dlopen, así que no rompen el arranque
sino un `import` — un fallo que aparece lejos y no menciona a python.
Resultado, con todo aplicado: 29 huecos -> 6, y los que quedan son otra clase.
`libperl.so` es empaquetado de la receta perl; `libc.so.6` lo pide el `go`
prebuilt y es un soname de GLIBC en una distro musl, que es un síntoma distinto.
Los dos quedan anotados en docs/state/sonames.txt, que ahora se regenera solo.
Sergio
02facebe28