From adeda7e4999560759e89356da47445076acf653a Mon Sep 17 00:00:00 2001 From: Sergio Date: Thu, 10 Sep 2026 21:13:30 +0000 Subject: [PATCH] =?UTF-8?q?recetas:=20takana=20se=20empaqueta=20a=20s?= =?UTF-8?q?=C3=AD=20mismo=20=E2=80=94=20y=20el=20alias=20del=20ADR=200016?= =?UTF-8?q?=20volv=C3=ADa=20al=20crate=20INEMPAQUETABLE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El corpus construía 869 recetas y no la suya. `takana` sólo existía como `cargo build --release` sobre un clon del repo, y eso bloqueaba lo de arriba de todo del SDD 28: que un servidor takana se sirva sus propios paquetes **a su propio host**. El host necesita `takana` instalado para consumir el repo, y no podía instalarlo DESDE el repo porque no estaba en el repo. **El muro, que nadie había tocado porque takana nunca se había empaquetado:** `takana-cli` declara DOS `[[bin]]` sobre el mismo `main.rs` (`takana` y `hammer`, la compatibilidad de la etapa 2 del ADR 0016). El camino Cargo del corpus invoca `cargo rustc … -- -C target-feature=+crt-static`, y `cargo rustc` con argumentos extra **sólo admite UN target**: error: extra arguments to `rustc` can only be passed to one target, consider filtering the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target O sea: la decisión de emitir dos binarios —tomada para que el alias sobreviviera a `cargo clean` y a la siembra de la granja, que excluye `/target`— hacía que el crate no se pudiera empaquetar. Se resuelve con `--bin takana` y reponiendo `hammer` como ENLACE en la fase de instalación: en el árbol de build un symlink no sobrevive, pero en el ARTEFACTO sellado es permanente y no duplica los megas. Y ese alias tapa un agujero real: **`arje-zero` todavía invoca el binario por el nombre viejo** — en el primer arranque de la caja de producción se leyó `hammer no corre, sin menú de arranque`. Viene pineado desde tawasuyu, así que no se arregla desde este repo; mientras `hammer` esté en el artefacto, el menú de arranque por grafo del ADR 0010 tiene qué ejecutar. Cuando la etapa 6 retire el alias, hay que subir arje-zero ANTES. Sellado `b3:941d1857…`, 3,3 M con el split de debug. Verificado: ELF estático, `takana --version` y `hammer --version` dan los dos `takana 0.0.1`. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x --- recipes/takana.toml | 54 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 recipes/takana.toml diff --git a/recipes/takana.toml b/recipes/takana.toml new file mode 100644 index 00000000..bcb9b0c8 --- /dev/null +++ b/recipes/takana.toml @@ -0,0 +1,54 @@ +# takana — EL BINARIO DEL PROYECTO, empaquetado como una receta más del corpus. +# +# POR QUÉ EXISTE (SDD 28 §3.4). El corpus construía 869 recetas y no la suya: `takana` sólo existía +# como `cargo build --release` sobre un clon del repo. Eso bloqueaba lo de arriba de todo — que un +# servidor takana **se sirva sus propios paquetes a su propio host**: el host necesita `takana` +# instalado para consumir el repo, y no podía instalarlo DESDE el repo porque no estaba en el repo. +# +# Receta Cargo, mismo patrón que `hammerd`/`netup`/`arje-zero`: crate del workspace takana a un +# commit fijado (ADR 0006), deps vendoreadas en el fetch para un build hermético `--offline`, enlace +# estático con `zig cc`. Sin dependencias C: el CLI es Rust puro (clap/serde/toml/nix/tracing). +# +# ⚠ EL ALIAS DEL ADR 0016 VOLVÍA AL CRATE INEMPAQUETABLE, y se descubrió acá porque takana nunca se +# había empaquetado. `takana-cli` declara DOS `[[bin]]` sobre el mismo `main.rs` (`takana` y `hammer`, +# la compatibilidad de la etapa 2). El camino Cargo del corpus invoca `cargo rustc … -- -C +# target-feature=+crt-static`, y **`cargo rustc` con argumentos extra sólo admite UN target**: +# +# error: extra arguments to `rustc` can only be passed to one target, consider filtering +# the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target +# +# Por eso `--bin takana` en los flags. Y `hammer` se repone en la fase de instalación como ENLACE, no +# como segundo binario: en el ÁRBOL DE BUILD un symlink no sobrevive (`cargo clean` lo borra y la +# siembra de la granja excluye `/target` — por eso el ADR eligió dos `[[bin]]`), pero en el ARTEFACTO +# sellado es permanente y no duplica los megas. +# +# Que `hammer` esté en el artefacto TAPA además un agujero real: `arje-zero` todavía invoca el binario +# por el nombre viejo — en el primer arranque de la caja de producción se leyó `hammer no corre, sin +# menú de arranque` — y viene pineado desde tawasuyu, así que no se arregla desde este repo. Cuando la +# etapa 6 retire el alias, hay que subir arje-zero ANTES. + +name = "takana" +version = "0.0.1" +license = "MIT" + +[source] +# El repo del propio takana: el `commit` es el identificador inmutable; la URL es sólo locator y no +# entra en `hash_inputs` (ADR 0013 §1). Subirlo cuando el CLI avance. +repo = "ssh://gitea@git.gioser.net:2345/sergio/takana.git" +commit = "3ff7585aa251913acad6fd26d9142da408bd02f9" + +[build] +compiler = "zig-cc" +target = "x86_64-linux-musl" +link = "static" + +# Split de la info de depuración (SDD 23 etapa 4). Entra en `hash_inputs`. +strip_debug = true +flags = ["-p", "takana-cli", "--bin", "takana"] + +[build.phases] +# Sobrescribe el `find target/release …` por defecto: hay que reponer el alias `hammer` (ver arriba). +install = "mkdir -p /out/usr/bin && cp target/release/takana /out/usr/bin/takana && ln -s takana /out/usr/bin/hammer" + +[deps] +build = ["binutils"]