From a35f4dcf1a27e2ab2f77369ddcbeac81c9bc9561 Mon Sep 17 00:00:00 2001 From: Sergio Date: Wed, 9 Sep 2026 18:48:14 +0000 Subject: [PATCH] =?UTF-8?q?ADR=200016:=20etapa=204=20(crates)=20y=20por=20?= =?UTF-8?q?qu=C3=A9=20las=20variables=20de=20entorno=20son=20unidad=20apar?= =?UTF-8?q?te?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Los 10 crates de librería + CLI renombrados, con los dos binarios congelados y su razón. Anotada la consecuencia real: renombrar hammer-core mueve los bytes de hammerd igual, así que el baseline of_tree del selfhost hay que rehacerlo. Y la medición que cambia el plan: 'la variable HAMMER=' no existe como cosa única — son 14 variables, ~260 apariciones, y el BINARIO las lee (HAMMER_LAB, HAMMER_ZIG, HAMMER_WORK, HAMMER_ROOTFS, HAMMER_MIRROR_KEY, HAMMER_LLM_*). Con knobs de instalador entre ellas y el entorno del worker trayéndolas puestas desde fuera del repo. Eso es contrato de usuario, no churn: pide leer las dos con caída a la vieja, que es código, no sed. Sumada la evidencia del worker: tras reiniciar el servicio compiló los dos binarios y cerró un ciclo real (dunst sellado, 1/1). --- docs/adr/0016-renombre-takana.md | 41 +++++++++++++++++++++++++++++++- 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/docs/adr/0016-renombre-takana.md b/docs/adr/0016-renombre-takana.md index 69584579..057a8a6e 100644 --- a/docs/adr/0016-renombre-takana.md +++ b/docs/adr/0016-renombre-takana.md @@ -100,7 +100,46 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con La unit apunta a la RUTA DEL SCRIPT, no al binario, así que nada de la etapa 3 la toca. El nombre del fichero de unit y `/opt/hammer` son etapa 6. -4. **Crates** `hammer-*` → `takana-*` y `hammerd` → `takanad`. + + **Convergido y comprobado (2026-09-09 18:40–18:45Z).** Reiniciado `hammer-farm.service`, el + worker compiló los dos binarios y **cerró un ciclo de build real con el nombre nuevo**: + `✓ dunst b3:29a79859…`, BUILD-YIELD 1/1, 1 promovido. No es que «no se rompió nada visible»: el + camino de construir y sellar se ejercitó entero. +4. **Crates.** ← *hecho parcialmente (2026-09-09)*. Los 10 de librería + CLI + (`hammer-{core,build,bootstrap,overlay,journal,mirror,upgrade,agent,recover,cli}`) son + `takana-*`. **Verificado que no mueve el corpus**: `takana hash recipes/zlib.toml` devuelve + `b3:dc363f26…`, idéntico a antes. 600 tests en verde. + + **Dos binarios congelados, con razón medida:** + - `hammerd` — paquete **y** binario. Es componente de Stage 1 de la distro (musl, busybox, + hammerd, arje-zero), arje-zero lo supervisa en el sistema arrancado y `PRESEED=hammerd` lo + nombra en `selfhost-verify.sh`. + - `hammer-recover` — el paquete es `takana-recover`, **el binario sigue siendo + `hammer-recover`**: `hammer-live-install.sh` lo copia a `/usr/sbin/hammer-recover` en sistemas + **ya instalados** y hornea un hook de arranque que lo invoca por ese nombre. Renombrarlo no + rompe el repo: rompe máquinas instaladas. + + **Consecuencia que hay que anotar igual:** al renombrar `hammer-core`, los bytes de `hammerd` + cambian de todos modos —linkea contra un crate con otro nombre y el nombre va en los símbolos—, + así que **el baseline `of_tree` del selfhost hay que rehacerlo**. Es efecto de la etapa 4, no de + un cambio en `hammerd`. + +4 bis. **Las variables de entorno son su propia unidad, no la cola de la 4.** Se midió antes de + tocarlas y el problema tiene otra forma que la que suponía el plan: no es «la variable + `HAMMER=`», son **14** (`HAMMER`, `HAMMER_DIR`, `HAMMER_BIN`, `HAMMER_STORE`, `HAMMER_MUSL`, + `HAMMER_MIRROR`, `HAMMER_TZ`, `HAMMER_KEYMAP`, `HAMMER_KERNEL`, `HAMMER_HOSTNAME`, `HAMMER_ZIG`, + `HAMMER_WORK`, `HAMMER_ROOTFS`, `HAMMER_LIVE`, `HAMMER_CACHE`), ~260 apariciones en 58 ficheros, + **y el binario las lee**: `HAMMER_LAB`, `HAMMER_ZIG`, `HAMMER_WORK`, `HAMMER_ROOTFS`, + `HAMMER_MIRROR_KEY`, `HAMMER_LLM_*`. + + ⇒ **Son contrato de usuario, del mismo tipo que un verbo de CLI**, no churn interno: hay knobs + del instalador (`HAMMER_TZ`, `HAMMER_KEYMAP`, `HAMMER_HOSTNAME`), el entorno del worker las trae + puestas (`mirror-env.sh`) y quedan fuera del repo, en perfiles de shell y units. Un `sed` las + rompe en silencio. + + El patrón correcto es el mismo que el resto del renombre: **leer las dos, preferir la nueva** + (`TAKANA_X` con caída a `HAMMER_X`), lo que es un cambio de código en Rust más un barrido de + scripts. Va como unidad propia, con su decisión. 5. **Comentarios de recetas** (692). Gratis en hash, ruidoso en diff: va en un commit propio y solo. 6. **Retirar el alias.** Y recién entonces, si se quiere, el directorio `/mnt/vvv/hammer` — parando el cron y reescribiendo el crontab en el mismo movimiento.