Sin una `configure` explícita hammer auto-detecta CMake (utf8proc trae CMakeLists.txt además del
Makefile) y genera `cmake -S . -B _build …`. Sellaba en el laptop —cuyo rootfs Alpine trae cmake— y
moría en el worker con `cmake: not found`, porque su rootfs NO lo trae: los dos rootfs no son
iguales (291 binarios vs 279). El build real es el Makefile; la salida no es declarar cmake sino no
pedirlo.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`libinput` fallaba con "no suitable Python interpreter found" — un mensaje de AUTOTOOLS, y libinput
es meson puro: el que moría no era libinput sino su dep `libevdev`.
Causa raíz: el rootfs Alpine del worker NO trae python3; el del laptop SÍ. `libevdev` declaraba
sólo `pkgconf` pero su configure de autotools pide un intérprete Python y su compile es `make`, o
sea vivía de prestado del rootfs. Sellaba en el laptop y moría en el worker, arrastrando a libinput.
`utf8proc` es el mismo caso al desnudo: NO declaraba NADA y sus dos fases son `make`.
Es exactamente la deuda declarable del SDD 16 §harkaq: el store ya provee ambos ⇒ una línea en
`[deps]`. Se declara en vez de engordar el rootfs del worker porque así construyen en CUALQUIER
máquina, que es el punto; parchear el worker dejaría la receta igual de mentirosa.
Radio de re-sellado medido: 2 recetas (libevdev, utf8proc). El resto de la cadena afectada
(libinput, fcft, foot, mirada-*) ya estaba sin sellar.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cierra el userland foundational: foot (terminal Wayland) + su cadena de libs → canónicas + repo
firmado. incoming-clib queda VACÍO (todo el base-system promovido). Front (d) COMPLETO a nivel build.
sergioandClaude Opus 4.8