SergioandClaude Opus 5
d3b42f892d
`recipes/zstd.toml` construye **sólo `lib/`** —lo dice su propia cabecera, «build de lib/ (no CLI)»— porque lo que necesitan sus 13 consumidores (mesa, libadwaita, appstream, rsync, los `zstd-sys`) es `libzstd.a`. El binario nunca se construyó, y el agujero sólo se ve al instalar la distro en una máquina de verdad: **un takana recién instalado no puede desempacar su propio laboratorio**, porque el `tar` del rootfs es el de busybox (`tar: unrecognized option: zstd`) y `zstd` no existe. Hubo que extraer por tubería desde otro hub — y un hub que se instala solo no puede depender de eso. ⚠ **Y mi arreglo anterior estaba mal**: declaré `zstd` en `perfil.base` dando por hecho que traía el binario. Se destapó aplicándolo con `takana upgrade` en la caja: «✓ generación 1 aplicada, + 8 añadidos» y `zstd` seguía ausente, porque los 8 ficheros eran headers y `libzstd.a`. **El upgrade hizo exactamente lo que debía; lo que estaba mal era lo que le pedí que aplicara.** Corregido a `zstd-cli`. Variante y no ampliación de la canónica: `zstd` es dep de 13 recetas y `mesa` está entre ellas; re-hashearla arrastraría esa torre por un binario de 1 M que ninguna usa. Mismo criterio que las 23 variantes `*-shared`, con el eje en librería/herramienta en vez de estático/dinámico. Radio cero. `HAVE_ZLIB/LZMA/LZ4=0` a propósito: sin eso el Makefile las detecta del sysroot del LAB y el binario sale pidiendo sonames que el artefacto no publica. Verificado: estático, 0 intérpretes requeridos, `Zstandard CLI v1.5.7`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
56 lines
3.0 KiB
TOML
56 lines
3.0 KiB
TOML
# zstd-cli 1.5.7 — la HERRAMIENTA `zstd`, que la receta canónica no produce.
|
|
#
|
|
# ── POR QUÉ EXISTE ──────────────────────────────────────────────────────────────────────────────
|
|
# `recipes/zstd.toml` construye **sólo `lib/`** («build de lib/ (no CLI)», dice su cabecera) porque
|
|
# lo que necesitan sus 13 consumidores —mesa, libadwaita, appstream, rsync, los `zstd-sys` de Rust—
|
|
# es `libzstd.a`. El binario nunca se construyó, y eso dejó un agujero que sólo se ve al instalar la
|
|
# distro en una máquina de verdad:
|
|
#
|
|
# $ tar --zstd -tf lab-image.tar.zst
|
|
# tar: unrecognized option: zstd ← el tar del rootfs es el de busybox
|
|
# $ zstd --version
|
|
# sh: zstd: not found
|
|
#
|
|
# **Un takana recién instalado no puede desempacar su propio laboratorio.** La distro comprime todo
|
|
# con zstd (la imagen del lab, el respaldo al Storage Box, el `dd` remoto de una instalación) y no
|
|
# traía con qué descomprimirlo: había que extraer por tubería desde otro hub. Un hub que se instala
|
|
# solo no puede depender de que otro hub le descomprima las cosas (SDD 28 §6.6).
|
|
#
|
|
# Y hay un segundo consumidor: `scripts/respaldo-storagebox.sh` usa `--compress-choice=zstd` —el
|
|
# doble de rendimiento efectivo, medido— que rsync sólo ofrece si lo encuentra al construirse.
|
|
#
|
|
# ── POR QUÉ UNA VARIANTE Y NO AMPLIAR LA CANÓNICA ───────────────────────────────────────────────
|
|
# `zstd` es dep de **13 recetas**, y `mesa` está entre ellas. Ampliar la canónica re-hashea la lib y
|
|
# arrastra en cascada toda esa torre por un binario de 700 K que ninguna de ellas usa. Mismo criterio
|
|
# que las variantes `*-shared` (23 en el corpus): la canónica no se mueve, el nombre es distinto, y
|
|
# cada consumidor toma la que necesita. Acá el eje no es estático/dinámico sino **librería/herramienta**.
|
|
#
|
|
# Radio: cero. Nadie depende de `zstd-cli`; sólo la declara `perfil.base` como raíz.
|
|
|
|
name = "zstd-cli"
|
|
version = "1.5.7"
|
|
license = "BSD-3-Clause OR GPL-2.0-only"
|
|
|
|
[source]
|
|
tarball = "https://github.com/facebook/zstd/releases/download/v1.5.7/zstd-1.5.7.tar.gz"
|
|
sha256 = "eb33e51f49a15e023950cd7825ca74a4a2b43db8354825ac24fc1b7ee09e6fa3"
|
|
|
|
[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 = []
|
|
|
|
[deps]
|
|
build = ["make"]
|
|
|
|
[build.phases]
|
|
# `programs/` construye el ejecutable y enlaza la lib del propio árbol; no hace falta la canónica.
|
|
# HAVE_ZLIB/LZMA/LZ4=0: sin esas deps el Makefile de zstd las detectaría del sysroot del LAB y el
|
|
# binario saldría pidiendo sonames que el artefacto no publica — la fuga de [[needed-colgante]].
|
|
compile = 'make -C programs zstd HAVE_ZLIB=0 HAVE_LZMA=0 HAVE_LZ4=0 CFLAGS="-O3"'
|
|
install = 'mkdir -p /out/usr/bin && cp programs/zstd /out/usr/bin/zstd'
|