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…

⎇ main recipes/zsh.toml TOML · 183 líneas · 10.3 KB Historia crudo

zsh: dejar de pedir `install.info` — fallaba siempre y sellaba un `/usr/share/info` VACÍO 3b36e9df0 · Sergio ·

1# zsh 5.9 — **el shell del usuario**, y por eso entra al piso y no a los extras.
2#
3# ══ POR QUÉ ESTA RECETA EXISTE ═════════════════════════════════════════════════════════════════
4# Barrido del 2026-09-16 sobre la laptop del usuario: su shell de login es zsh (1611 `cd`, 1054
5# `cargo`, 134 `zellij` en el historial), y zsh **no tenía receta en el corpus ni en ninguna de las
6# cuatro colas**. Una imagen de takana instalada en esa máquina la dejaba en `bash` — funciona, pero
7# no es su máquina. Es el mismo hueco de RUNTIME que `bash-completion` en `[perfil.base]`: nadie lo
8# alcanza por deps de build, así que ninguna métrica de deuda podía verlo.
9#
10# ⚠ **PUNTO DE PARTIDA, NO SELLADA.** Escrita en el laptop, que no tiene lab ni store (su
11# `.dev-fs/alpine` tiene 104 paquetes contra los 110 de `lab-toolchain.lock`, así que ni siquiera
12# calcula hashes comparables). El primer build va en el worker. Lo que sigue son las trampas
13# conocidas de hermanos ya sellados, anotadas para que el primer build no las redescubra.
14#
15# ══ LOS SEIS PARCHES SON DE ALPINE, Y NO SON OPCIONALES ════════════════════════════════════════
16# Vienen de `main/zsh` de aports y son el trabajo de portabilidad a musl que un import de nix
17# pierde. `implicit.patch` (16 K) es el gordo: declaraciones implícitas que gcc14/clang rechazan
18# como error. Los otros cinco son tests que no aplican fuera de glibc, el instalador de usuario
19# nuevo de Alpine, punteros incompatibles de gcc14 y el cacheo de `man -w`.
20#
21# ══ RIESGO CONOCIDO PARA EL PRIMER BUILD (heredado de bash.toml) ═══════════════════════════════
22# ✅ **PASÓ, Y LA PREDICCIÓN ERA CORRECTA** (primer build, 2026-09-17): el artefacto salió
23# `dynamically linked, interpreter /lib/ld-musl-x86_64.so.1` y murió con el síntoma exacto anotado
24# acá arriba:
25#
26#     Error relocating /lib/libncursesw.so.6: __vfprintf_chk: symbol not found
27#
28# —o sea, se enlazó contra la ncurses del LAB de Alpine, que ninguna imagen de takana tiene—.
29#
30# La causa de fondo es más honda que el `-rdynamic` de bash: **zsh construye sus módulos como `.so`
31# y los carga con `dlopen`**, y un binario que hace `dlopen` no puede ser estático. Por eso el
32# arreglo no es sólo tirar la bandera, es `--disable-dynamic`: los módulos quedan ENLAZADOS DENTRO
33# del binario. Se pierde `zmodload` de un `.so` de fuera —que en una distro de artefactos sellados
34# no tiene sentido— y se gana un zsh que arranca. `make LOCAL_LDFLAGS=` queda igual, por si el
35# `configure` mete `-rdynamic` de todas formas.
36#
37# Y el control **va en la receta**, no en la cabeza de quien la corra: la fase de instalación
38# pregunta por el `INTERP` del ELF con el `readelf` de binutils (que ya es dep) y CORTA si aparece.
39# Un zsh dinámico sella, reproduce y no arranca: es [[needed-colgante-libstdcxx]] otra vez, y sin el
40# guardián no se descubre hasta que alguien abre una terminal dentro de la imagen.
41#
42# ══ Y `--disable-dynamic` NO LINKEA LOS MÓDULOS: LOS APAGA ═════════════════════════════════════
43# Segundo build, y el binario ya era estático — pero `zmodload -L` decía **`zsh/main` y nada más**:
44#
45#     $ zsh -c '[[ "takana-2026" =~ "^takana-[0-9]+$" ]]'
46#     zsh:1: failed to load module: zsh/regex
47#     zsh:1: -regex-match not available for regex
48#
49# O sea un zsh sin `=~`, que es de las cosas que más se escriben en un script. Los que sí estaban
50# —`zsh/complete`, `zsh/zle`— confunden más, porque el completado funciona y parece que está todo.
51#
52# ⚠ **Dos explicaciones mías fueron FALSAS antes de la buena. Las dejo escritas porque las dos son
53# plausibles y cuestan un build cada una.**
54#
55#   1ª) «`--disable-dynamic` deja los módulos en `link=dynamic` y hay que pasarlos a `static` con un
56#       `sed` sobre `config.modules`». El `sed` no cambió nada: los disponibles YA salían `static`.
57#   2ª) «el `link=` del `.mdd` evalúa `$ac_cv_func_regcomp` y `config.status` no tiene esas variables,
58#       así que hay que EXPORTARLAS». Tampoco: el configure contesta `yes` a las cuatro y el módulo
59#       seguía fuera.
60#
61# Lo que zanjó el asunto fue leer `configure.ac`, que no opina — decide:
62#
63#     case "$link" in
64#       dynamic) if test x$dynamic != xno; then … else  link=no   fi ;;   ← ACÁ
65#       either)  if test x$dynamic != xno; then … else  link=static fi ;;
66#
67# O sea: con `--disable-dynamic`, un módulo que su `.mdd` declara **`dynamic` se DESCARTA**, y sólo
68# los que declaran **`either`** pasan a estático. `Src/Modules/regex.mdd` dice `echo dynamic`, y
69# `Src/Zle/complete.mdd` dice `either`: por eso había completado y no había `=~`. No era el entorno
70# ni el orden: era el vocabulario del `.mdd`.
71#
72# Por eso el arreglo va sobre los `.mdd`, ANTES del configure —`dynamic` → `either`—, que además
73# sobrevive a que `make` regenere `config.modules` (lo regenera: corre `config.status` de nuevo).
74# A los que les falta su librería el `.mdd` les hace decir `no`, y esos siguen fuera, que es correcto.
75#
76# La lección general: `checking for regcomp... yes` en el log **no** implica que el módulo que lo
77# necesita se construya. Lo que manda es `config.modules`, y ahí el estado era `link=no`.
78#
79# ══ `--enable-pcre` ERA UNA ETIQUETA, NO UN HECHO ══════════════════════════════════════════════
80# zsh 5.9 sólo habla **PCRE1** (busca `pcre-config` y `pcre.h`); el corpus tiene **pcre2**. El
81# configure lo dijo tres veces —`checking for pcre-config... no`, `pcre.h... no`,
82# `pcre_compile... no`— y la receta seguía declarando la bandera y la dep. Se quitan las dos: una dep
83# que no se usa miente sobre el cierre y una bandera que no engancha miente sobre la capacidad.
84# `=~` no la necesita: lo resuelve `zsh/regex` sobre la regex de libc.
85name    = "zsh"
86version = "5.9"
87license = "MIT"
88
89[source]
90tarball = "https://sourceforge.net/projects/zsh/files/zsh/5.9/zsh-5.9.tar.xz"
91# sha256 calculado sobre el tarball bajado el 2026-09-16 (Alpine publica sha512, no sha256).
92sha256  = "9b8d1ecedd5b5e81fbf1918e876752a7dd948e05c1a0dba10ab863842d45acd5"
93patches = [
94  "implicit.patch",
95  "fix-gcc14-incompatible-pointer-types.patch",
96  "zsh-newuser-install-alpine.patch",
97  "0001-50278-use-man-w-in-preference-to-manpath-fix-caching.patch",
98  "skip-test-failing-on-musl.patch",
99  "tests-user.patch",
100]
101
102[build]
103compiler = "zig-cc"
104target   = "x86_64-linux-musl"
105link     = "static"
106# Split de la info de depuración (SDD 23 etapa 4). Entra en `hash_inputs`.
107strip_debug = true
108flags    = []
109
110[build.phases]
111# de build() de Alpine (traducido; el lab provee $CBUILD/$CHOST).
112#
113# `--enable-function-subdirs` + `--enable-fndir`: zsh instala ~1200 ficheros de funciones en
114# `/usr/share/zsh/functions`. NO se recortan: sin ellas no hay `compinit`, y un zsh sin completado
115# es justamente lo que el usuario no tiene hoy. Es la lección de CLAUDE.md §3 al revés — acá el
116# artefacto "completo" son los datos, no el binario.
117#
118# `--disable-gdbm` es deliberado: gdbm no está en el corpus y sólo aporta el módulo `zsh/db/gdbm`.
119# Encenderlo pediría una receta más para una capacidad que nadie pidió.
120compile = '''
121_abuild_phase() {
122	# Ver la nota de arriba: con `--disable-dynamic`, lo que el `.mdd` declara `dynamic` se DESCARTA
123	# y sólo lo que declara `either` queda estático. Esto reescribe ese vocabulario antes de que el
124	# configure lo lea; los `.mdd` que dicen `no` por falta de librería siguen diciendo `no`.
125	sed -i "s/echo dynamic/echo either/; s/^link=dynamic$/link=either/" Src/*/*.mdd Src/*/*/*.mdd
126	./configure \
127		--build=$CBUILD \
128		--host=$CHOST \
129		--prefix=/usr \
130		--bindir=/bin \
131		--enable-etcdir=/etc/zsh \
132		--enable-cap \
133		--enable-multibyte \
134		--enable-function-subdirs \
135		--enable-fndir=/usr/share/zsh/functions \
136		--enable-zsh-secure-free \
137		--disable-gdbm \
138		--disable-dynamic \
139		--sysconfdir=/etc \
140		--mandir=/usr/share/man \
141		--infodir=/usr/share/info \
142		--with-tcsetpgrp
143	# Los módulos ADENTRO del binario: `--disable-dynamic` por sí solo los deja fuera.
144	make LOCAL_LDFLAGS=
145}
146_abuild_phase
147'''
148# de package() de Alpine (traducido $pkgdir→/out). Sin locales: el corpus no los hidrata y pesan.
149install = '''
150_abuild_phase() {
151	make LOCAL_LDFLAGS= DESTDIR="/out" install
152	rm -rf "/out"/usr/share/locale
153	# `install.info` NO se pide, y no es una poda de tamaño como la de arriba: MEDIDO el
154	# 2026-09-18, `makeinfo` no está en el lab, así que fallaba SIEMPRE
155	# (`/bin/sh: makeinfo: not found` ⇒ `make: *** [Makefile:255: install.info] Error 2`).
156	# Y el build SELLABA IGUAL, dejando un `/usr/share/info` vacío adentro: las fases corren
157	# con `/bin/sh -c` SIN `-e` (`takana-build/src/sandbox.rs:332,491`), así que un fallo a
158	# mitad de fase no aborta nada — sólo cuenta el estado del ÚLTIMO comando. Un directorio
159	# vacío en el artefacto es la regla 3 de CLAUDE.md en pequeño: llega hasta el final
160	# diciendo que todo fue bien. Pedir algo que no puede funcionar y tolerar su fallo es
161	# peor que no pedirlo.
162	rm -rf "/out"/usr/share/info
163	# `/etc/shells` no se escribe acá: es estado del sistema instalado, no del artefacto.
164	# GUARDIÁN: un zsh dinámico sella, reproduce y NO ARRANCA dentro de una imagen (pide
165	# libncursesw.so.6, que nadie provee). Se comprueba el hecho en el ELF, no la intención.
166	if readelf -l /out/bin/zsh | grep -q INTERP; then
167		echo "zsh: el binario salió DINÁMICO (tiene INTERP) — pediría libncursesw.so.6 dentro de la imagen y moriría con 'Error relocating'. Mirar si el configure volvió a meter -rdynamic"
168		exit 1
169	fi
170	# Y que los módulos estén DENTRO: un zsh sin `zsh/regex` no tiene `=~`, y eso no se nota
171	# hasta que un script lo usa. Se pregunta al binario, que es quien sabe.
172	for m in zsh/regex zsh/complete zsh/zle zsh/parameter; do
173		if ! /out/bin/zsh -fc "zmodload $m" 2>/dev/null; then
174			echo "zsh: falta el módulo $m dentro del binario — mirar config.modules tras el configure (¿quedó link=dynamic?)"
175			exit 1
176		fi
177	done
178}
179_abuild_phase
180'''
181
182[deps]
183build = ["binutils", "ncurses", "libcap", "linux-headers", "make"]