gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1576Shell 205Rust 111Markdown 993774 Definitions

⎇ 6f9672494e1f44230f4c1ccc115b0f1e89353d84 docs/33-versionado-y-relojes.md Markdown · 123 lines · 6.5 KB History raw

SDD 33 + la vigía de río arriba: 660 fuentes git en 17 s, y 462 tienen algo más nuevo a13edfa9c · Sergio ·

1# SDD 33 — Versionar takana: cómo se llama una versión, qué reloj mira qué, y qué se cambia solo
2
3> **Estado: PROPUESTA, con la primera pieza IMPLEMENTADA y medida** (2026-09-23):
4> `scripts/fuentes/upstream-vigia.py`. Lo demás está decidido y no construido, y se dice cuál es
5> cuál.
6
7## 0. La pregunta
8
9> *¿cómo ir versionando esto? hay las actualizaciones desde los orígenes que hay que adaptar las
10> recetas, por ejemplo ya está kernel 7.3. y lo que voy desarrollando de tawasuyu que avanza rápido.*
11
12Son **tres** preguntas y conviene no mezclarlas, porque cada una se contesta distinto:
13
141. **Cómo se LLAMA una versión** de takana — hoy no se llama de ninguna manera.
152. **Quién mira qué se movió río arriba**, y cada cuánto.
163. **Qué se puede cambiar solo** y qué no. Ésta es la única con filo.
17
18## 1. Una versión ya existe, y no es un número
19
20La identidad real de una imagen **ya está**: es el hash de la clausura de su perfil. No se puede
21falsificar, no depende de quién la armó y dos imágenes con el mismo hash son la misma imagen. Eso es
22mejor que cualquier número, y es lo que el sistema usa para todo.
23
24Lo que falta es un nombre que una persona pueda decir en voz alta. Propuesta:
25
26| | |
27|---|---|
28| **identidad** | `b3:<hash de la clausura del perfil>` — exacta, la que verifica |
29| **nombre** | `takana AÑO.MES[.n]` — `takana 2026.09`, y `2026.09.2` si hay más de una en el mes |
30| **dónde vive** | en la imagen (`/etc/os-release`), en el nombre del fichero publicado, y lo imprime el instalador antes de tocar el disco |
31
32⚠ **El nombre NO es la versión: es una etiqueta sobre ella.** Un fichero llamado
33`takana-2026.09-mirada.sh` tiene que decir de qué clausura salió, porque el día que alguien
34reconstruya para comprobar, lo que compara es el hash. Publicar sólo el nombre es la forma barata de
35que el sitio empiece a mentir — que es lo que ya pasó con un sha256 pegado a mano en la página.
36
37## 2. Tres relojes, no dos, y ya hay uno andando
38
39| reloj | cada | qué hace | estado |
40|---|---|---|---|
41| **cosecha** | 30 min | trae del worker lo que se selló, siembra recetas, regenera el estado y commitea | **anda** (`scripts/farm/cosecha-cron.sh`) |
42| **río arriba** | 1 día | pregunta a cada fuente si hay algo más nuevo que el pin, y deja un informe | **la pieza implementada hoy** |
43| **medios** | cuando el cierre cambie | rearma imágenes e instaladores y publica | **falta** |
44
45### 2.1 Río arriba — `scripts/fuentes/upstream-vigia.py`
46
47Pregunta lo que `fuentes-vigia.sh` no pregunta. Aquél mira si la fuente **sigue viva**; éste mira si
48hay **algo más nuevo que lo que tenemos clavado**. Se confunden, y son las dos mitades: una fuente
49viva puede llevar dos años sin tocarse, y una que se movió ayer puede desaparecer mañana.
50
51Medido el 2026-09-23, primera corrida completa:
52
53```
54660 recetas con repo git · 17 s
55462 con un tag más nuevo que el pin
56606 con la rama movida desde el pin
57625 recetas pinean un TARBALL y esta vigía no las mira
58```
59
60**Por qué sólo git, y por qué eso ya es la mitad.** `git ls-remote` funciona contra cualquier
61servidor sin API, sin token y sin clonar — es lo mismo que ya hace `takana pin`. Con eso se cubren
62las 660 que pinean `repo` + `commit`. Un tarball no tiene equivalente general: saber si hay una
63versión nueva pide una pista por receta (dónde mirar, con qué patrón), y eso es su propia unidad de
64trabajo. **Se cuentan y se dicen**, no se adivinan: 625 recetas fuera del radar es un dato, no un
65silencio.
66
67⚠ **Sale 0 siempre.** Un guardián que falla porque upstream sacó una versión nueva grita todos los
68días y en una semana nadie lo mira ([[guardianes-el-ruido-los-mata]]).
69
70## 3. Qué se cambia solo — la única pregunta con filo
71
72> **Se automatiza el pin de lo NUESTRO. No se automatiza el de nadie más.**
73
74### 3.1 tawasuyu: sí, y de a un repo entero
75
76Son **37 recetas sobre el MISMO monorepo**, y ahí está la trampa: bumpear 37 pins de a uno da una
77imagen con 37 commits distintos del mismo árbol — mezcla de versiones que nunca existió junta y que
78nadie probó. El bump tiene que ser **atómico por repositorio**: todas las recetas que comparten
79`repo` saltan al mismo commit, o no salta ninguna.
80
81Es defendible automatizarlo porque es código propio, la granja lo reconstruye y los guardianes ven
82la rotura. Lo que **no** se automatiza ni ahí es publicar: un bump que compila no es un bump que
83arranca.
84
85### 3.2 Terceros: no, y el kernel 7.3 es el ejemplo
86
87Una versión nueva de upstream puede cambiar el sistema de build, las banderas, las dependencias y el
88resultado. Aplicarla sola es cambiar la receta sin leerla.
89
90El kernel lo muestra entero: pasar de 6.16 a 7.3 no es cambiar un número. Toca el contrato de
91kconfig (SDD 22), las opciones que nuestras imágenes exigen (`CONFIG_KEXEC_FILE`, el EFI-stub, el
92`CONFIG_CMDLINE` horneado del que depende el arranque del USB), los drivers de las máquinas que ya
93validamos, y las tasas del SDD 25. **Es una unidad de trabajo, no una línea de cron.**
94
95⇒ Para terceros la vigía **propone**: deja el informe, y quien decide aplica con `takana pin` y una
96construcción. Proponer y aplicar son verbos distintos y conviene que también sean comandos distintos.
97
98## 4. Cuándo rearmar los medios: por el CIERRE, no por el calendario
99
100Un cron semanal que rearma las imágenes gasta horas de worker para producir, casi siempre, **los
101mismos bytes**. El disparador correcto no es el tiempo: es que la clausura del perfil haya cambiado.
102
103```
104por cada perfil publicado:
105    h = hash de la clausura del perfil            (barato: `takana hash`, sin construir)
106    si h ≠ el hash de la imagen publicada:
107        rearmar, probar con los tres arneses, publicar
108```
109
110Y **publicar es lo último**, después de los arneses, nunca antes: hoy son 25 comprobaciones del
111banco, 13 del salto y 13 del USB, y las tres corren sin intervención.
112
113⚠ **El paso que falta y hay que escribir: la imagen publicada tiene que declarar de qué clausura
114salió.** Sin eso, la comparación de arriba no se puede hacer y el cron vuelve a ser un calendario.
115
116## 5. Lo que este documento NO decide
117
118- **La pista por receta para los tarballs** (625). Hace falta un campo tipo `[source.upstream]` con
119  dónde mirar y qué patrón; es su propia unidad.
120- **Si el nombre lleva mes o semana.** Depende de cada cuánto se publique de verdad, y eso todavía
121  no se sabe porque hoy se publica a mano.
122- **Firmar lo publicado.** Los `.sha256` de al lado comprueban la descarga, no la procedencia. El
123  repo de paquetes ya tiene firma (ADR 0014); las imágenes no, y son lo que más se copia.

33-versionado-y-relojes.md

SDD 33 — Versionar takana: cómo se llama una versión, qué reloj mira qué, y qué se cambia solo

Estado: PROPUESTA, con la primera pieza IMPLEMENTADA y medida (2026-09-23): scripts/fuentes/upstream-vigia.py. Lo demás está decidido y no construido, y se dice cuál es cuál.

0. La pregunta

¿cómo ir versionando esto? hay las actualizaciones desde los orígenes que hay que adaptar las recetas, por ejemplo ya está kernel 7.3. y lo que voy desarrollando de tawasuyu que avanza rápido.

Son tres preguntas y conviene no mezclarlas, porque cada una se contesta distinto:

  1. Cómo se LLAMA una versión de takana — hoy no se llama de ninguna manera.
  2. Quién mira qué se movió río arriba, y cada cuánto.
  3. Qué se puede cambiar solo y qué no. Ésta es la única con filo.

1. Una versión ya existe, y no es un número

La identidad real de una imagen ya está: es el hash de la clausura de su perfil. No se puede falsificar, no depende de quién la armó y dos imágenes con el mismo hash son la misma imagen. Eso es mejor que cualquier número, y es lo que el sistema usa para todo.

Lo que falta es un nombre que una persona pueda decir en voz alta. Propuesta:

identidadb3:<hash de la clausura del perfil> — exacta, la que verifica
nombretakana AÑO.MES[.n] — takana 2026.09, y 2026.09.2 si hay más de una en el mes
dónde viveen la imagen (/etc/os-release), en el nombre del fichero publicado, y lo imprime el instalador antes de tocar el disco

⚠ El nombre NO es la versión: es una etiqueta sobre ella. Un fichero llamado takana-2026.09-mirada.sh tiene que decir de qué clausura salió, porque el día que alguien reconstruya para comprobar, lo que compara es el hash. Publicar sólo el nombre es la forma barata de que el sitio empiece a mentir — que es lo que ya pasó con un sha256 pegado a mano en la página.

2. Tres relojes, no dos, y ya hay uno andando

relojcadaqué haceestado
cosecha30 mintrae del worker lo que se selló, siembra recetas, regenera el estado y commiteaanda (scripts/farm/cosecha-cron.sh)
río arriba1 díapregunta a cada fuente si hay algo más nuevo que el pin, y deja un informela pieza implementada hoy
medioscuando el cierre cambierearma imágenes e instaladores y publicafalta

2.1 Río arriba — scripts/fuentes/upstream-vigia.py

Pregunta lo que fuentes-vigia.sh no pregunta. Aquél mira si la fuente sigue viva; éste mira si hay algo más nuevo que lo que tenemos clavado. Se confunden, y son las dos mitades: una fuente viva puede llevar dos años sin tocarse, y una que se movió ayer puede desaparecer mañana.

Medido el 2026-09-23, primera corrida completa:

660 recetas con repo git · 17 s
462 con un tag más nuevo que el pin
606 con la rama movida desde el pin
625 recetas pinean un TARBALL y esta vigía no las mira

Por qué sólo git, y por qué eso ya es la mitad. git ls-remote funciona contra cualquier servidor sin API, sin token y sin clonar — es lo mismo que ya hace takana pin. Con eso se cubren las 660 que pinean repo + commit. Un tarball no tiene equivalente general: saber si hay una versión nueva pide una pista por receta (dónde mirar, con qué patrón), y eso es su propia unidad de trabajo. Se cuentan y se dicen, no se adivinan: 625 recetas fuera del radar es un dato, no un silencio.

⚠ Sale 0 siempre. Un guardián que falla porque upstream sacó una versión nueva grita todos los días y en una semana nadie lo mira ([[guardianes-el-ruido-los-mata]]).

3. Qué se cambia solo — la única pregunta con filo

Se automatiza el pin de lo NUESTRO. No se automatiza el de nadie más.

3.1 tawasuyu: sí, y de a un repo entero

Son 37 recetas sobre el MISMO monorepo, y ahí está la trampa: bumpear 37 pins de a uno da una imagen con 37 commits distintos del mismo árbol — mezcla de versiones que nunca existió junta y que nadie probó. El bump tiene que ser atómico por repositorio: todas las recetas que comparten repo saltan al mismo commit, o no salta ninguna.

Es defendible automatizarlo porque es código propio, la granja lo reconstruye y los guardianes ven la rotura. Lo que no se automatiza ni ahí es publicar: un bump que compila no es un bump que arranca.

3.2 Terceros: no, y el kernel 7.3 es el ejemplo

Una versión nueva de upstream puede cambiar el sistema de build, las banderas, las dependencias y el resultado. Aplicarla sola es cambiar la receta sin leerla.

El kernel lo muestra entero: pasar de 6.16 a 7.3 no es cambiar un número. Toca el contrato de kconfig (SDD 22), las opciones que nuestras imágenes exigen (CONFIG_KEXEC_FILE, el EFI-stub, el CONFIG_CMDLINE horneado del que depende el arranque del USB), los drivers de las máquinas que ya validamos, y las tasas del SDD 25. Es una unidad de trabajo, no una línea de cron.

⇒ Para terceros la vigía propone: deja el informe, y quien decide aplica con takana pin y una construcción. Proponer y aplicar son verbos distintos y conviene que también sean comandos distintos.

4. Cuándo rearmar los medios: por el CIERRE, no por el calendario

Un cron semanal que rearma las imágenes gasta horas de worker para producir, casi siempre, los mismos bytes. El disparador correcto no es el tiempo: es que la clausura del perfil haya cambiado.

por cada perfil publicado:
    h = hash de la clausura del perfil            (barato: `takana hash`, sin construir)
    si h ≠ el hash de la imagen publicada:
        rearmar, probar con los tres arneses, publicar

Y publicar es lo último, después de los arneses, nunca antes: hoy son 25 comprobaciones del banco, 13 del salto y 13 del USB, y las tres corren sin intervención.

⚠ El paso que falta y hay que escribir: la imagen publicada tiene que declarar de qué clausura salió. Sin eso, la comparación de arriba no se puede hacer y el cron vuelve a ser un calendario.

5. Lo que este documento NO decide