ADR 0016: cerrada la unidad de variables de entorno
Con lo que la medición cambió respecto del plan, los dos controles negativos del helper, y la distinción que importa: la caída sirve al lector NUEVO; donde el script exporta, hay que seguir poniendo la vieja porque el lector puede ser un binario viejo.
This commit is contained in:
@@ -124,22 +124,39 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
|
||||
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_*`.
|
||||
4 bis. **Variables de entorno: leen las dos, gana la nueva.** ← *hecho (2026-09-09)*.
|
||||
|
||||
⇒ **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.
|
||||
Se midió antes de tocarlas y el problema tenía otra forma que la del plan: no era «la variable
|
||||
`HAMMER=`», eran **14**, ~260 apariciones en 58 ficheros, **y el binario las lee**. Con knobs del
|
||||
instalador entre ellas, el entorno del worker trayéndolas puestas y `mirror-env.sh` exportándolas
|
||||
— todo eso vive **fuera del repo**, en perfiles de shell y units. Un `sed` no falla ruidosamente:
|
||||
la variable deja de aparecer, se toma el default y el build se comporta distinto en silencio.
|
||||
|
||||
- **Rust:** `takana_core::env::{var, var_os}` recibe el nombre **canónico** (`TAKANA_…`) y deriva
|
||||
el viejo cambiando el prefijo. Se le pasa el nuevo a propósito, para que un `grep` del nombre
|
||||
nuevo encuentre todas las lecturas. 5 tests, **con dos controles negativos**: sin ninguna de las
|
||||
dos no hay valor, y un nombre sin prefijo `TAKANA_` no inventa una caída.
|
||||
- Migrados los 17 sitios directos **y los indirectos que el grep de `env::var("HAMMER_…")` no
|
||||
mostraba**: `bases_de_mirror`, las constantes de `kernel_cmd`, `ROOT_ENV` de qorpa y `env_path`
|
||||
de recover. `takana-recover` lleva la caída **inline**: es un mini-binario que se copia a
|
||||
`/usr/sbin` y no vale arrastrarle una dep entera por dos líneas.
|
||||
- **Scripts:** 30 lecturas pasan a `${TAKANA_X:-${HAMMER_X:-default}}`, conservando el nombre
|
||||
**interno** de la variable para no tocar sus 190 usos.
|
||||
- **Donde el script EXPORTA en vez de leer, se ponen las dos** (`mirror-env.sh` y el fragmento
|
||||
in-VM de `takana-bootstrap`). Ahí el lector puede ser un binario **viejo** —un worker sin
|
||||
recompilar, el `/usr/bin/hammer` pinado del baseline— que sólo conoce `HAMMER_*`. La caída
|
||||
sirve al lector nuevo; al viejo hay que seguirle dejando la suya puesta.
|
||||
|
||||
**Verificado con el binario, no sólo con unit tests:** `HAMMER_LAB` sigue surtiendo efecto,
|
||||
`TAKANA_LAB` hace exactamente lo mismo, y con las dos puestas gana `TAKANA_LAB`. 605 tests en
|
||||
verde y `hash zlib` sigue en `b3:dc363f26…`.
|
||||
|
||||
**Cambio de comportamiento que va dicho aparte:** el hostname por defecto de una instalación
|
||||
nueva pasa de `hammer` a `takana` (sólo si no se fija ninguna de las dos variables).
|
||||
|
||||
**No se tocan:** las rutas `/var/lib/hammer` de sistemas ya instalados, el `-volid HAMMER_LIVE`
|
||||
del ISO (es identidad horneada en el medio) y el namespace `HARKAQ_*`, que es de otro subsistema.
|
||||
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user