RESULTADO, con los tres criterios medidos a la vez sobre las dos recetas que divergían:
bison 6M → 3M · 0 ficheros vacíos · 0 secciones .debug_ · «bison (GNU Bison) 3.8.2»
appstream 56M → 18M · 0 ficheros vacíos · 0 secciones .debug_ · «AppStream version: 1.0.5»
y las DOS pasan de DIVERGIR a REPRODUCIR.
O sea que un solo cambio recupera espacio Y cierra la fuga de reproducibilidad, como predijo el
§1.bis. Pero se llegó ahí después de tres errores que conviene dejar escritos.
🧨 1. `zig objcopy --strip-debug X X` (mismo fichero de entrada y salida) TRUNCA EL FICHERO A 0
BYTES. Destruyó los artefactos del piloto — y lo grave es que LOS TRES INDICADORES DECÍAN QUE
IBA BIEN: el tamaño cayó 84% (porque los ficheros quedaron vacíos), `why-differs` dijo REPRODUCE
(porque dos árboles vacíos son idénticos) y no quedaban secciones .debug_ (porque no quedaba
ninguna sección). Se cazó al EJECUTAR el binario: 0 bytes.
⇒ La verificación de un artefacto tiene que incluir que SIGA FUNCIONANDO, no sólo que pese menos
y reproduzca. Un artefacto vacío cumple las dos y no sirve para nada. Es la lección de esta
campaña aplicada a la campaña misma: una métrica que parece éxito.
2. Al arreglarlo con fichero temporal, el strip pasó a ser un NO-OP SILENCIOSO: los binarios
quedaban intactos y el tamaño no bajaba, porque no se pudo confirmar que `zig objcopy` acepte
`--strip-debug`. Cambiado al `strip` de binutils, que sí funciona, a costa de declarar la dep.
⇒ Preferible una dep explícita que funciona a una comodidad que no se sabe si hace algo.
3. Con el strip real, apareció una fuga NUEVA: los artefactos seguían divergiendo, ahora por la
CABECERA `ar` de los `.a` — `strip` los reescribe con los timestamps de cada corrida. Lo nombró
`why-differs` exacto («archivar en modo determinista»). Arreglado con `strip -D`
(= --enable-deterministic-archives). ⇒ Arreglar media causa deja el invariante igual de roto: el
debug ya no divergía y el archivo sí.
DISEÑO: `strip_debug` es un campo de la receta que ENTRA en `hash_inputs` y sólo si está fijado
(mismo patrón que `zig_version`). Las dos mitades importan y están clavadas en un test: si no
entrara, el lab cambiaría el contenido del artefacto sin mover el hash y el store MENTIRÍA; y al
entrar sólo si está fijado, se despliega receta a receta sin re-hashear las 1161 de golpe —
verificado: con el campo añadido al código, los 1161 hashes existentes NO se movieron.
Va como paso del lab y no en la fase install de cada receta porque 383 de las 1161 no tienen
install explícita: meterlo receta a receta obligaría a escribir a mano ese install por defecto en
las 383, con riesgo de no clavarlo exacto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5
fbd586f9b2