Files
sergioandClaude Opus 5 346cd59706 licencias: campo license en la receta — de 0 a 228 de 1141, sin re-hashear nada
La deuda legal bloqueante del SDD 19 §2.1. Medido hoy: **0 de 1141 recetas** declaraban
licencia, no «5 de 771» como decía el informe anterior. Los dos números estaban mal: los
«5» eran falsos positivos de `grep license` (el paquete `addlicense`, el paquete
`cargo-bundle-licenses`, una línea `install .../share/licenses/` y un comentario), y las
recetas son 1141. Contar con `grep -l <palabra>` sobre TOML cuenta comentarios y nombres,
no campos; `scripts/licencias.sh` cuenta el campo de verdad (clave en la raíz, antes del
primer `[table]`).

LO QUE HACE LA DEUDA PAGABLE: `Recipe::hash_inputs` es una LISTA BLANCA — sólo entran
source, compiler, target, link, patches, flags, phases y deps. `license` no entra, igual
que `evidence` y `slots`. Por eso se puede poblar en las recetas YA SELLADAS sin mover un
solo ArtifactHash. Verificado, no supuesto: en 40 recetas modificadas se comparó el hash
con y sin la línea — 40 idénticos, 0 cambiados. Si el campo entrara al hash, declarar la
licencia costaría reconstruir el corpus entero y no se haría nunca. Clavado con el test
`licencia_round_trip_y_no_afecta_el_hash`.

TRAMPA DE TOML: una clave suelta después de un `[table]` pertenece a esa tabla. Puesta al
final del fichero, `license` acaba dentro de `[deps]` y se pierde EN SILENCIO, porque serde
ignora los campos que no conoce — no hay error, simplemente no está. Va arriba, junto a
`name` y `version`; el sembrador la inserta tras `version`.

NO SE ADIVINA. Declarar mal una licencia es peor que dejarla vacía: convierte un hueco
visible en una afirmación falsa. Sólo se puebla desde una tabla curada entrada por entrada
(`docs/licencias-conocidas.tsv`); lo que no tiene evidencia queda vacío y se CUENTA.
Concretamente se descartó el atajo «k* = KDE ⇒ LGPL»: en este catálogo `kail`, `kind`,
`ko`, `kopia`, `krew`, `kustomize`, `kyverno`, `katana`, `kibi`, `kmon` y toda la familia
`kube*` son herramientas Go sin relación con KDE. El nombre no es evidencia.

Quedan 913, casi todas CLIs Go/Rust importados en masa — y ésas sí son automatizables con
evidencia real: Cargo.toml trae el campo `license` y los módulos Go traen su LICENSE en el
árbol. El cierre estructural es capturarlo en la fase de fetch, que ya descarga y extrae
cada tarball, y inyectar el texto en `hammer pack` (aguas abajo del ArtifactHash) en vez de
en la fase install (que sí re-hashearía).

De paso, respaldo-storagebox.sh reordenado por valor irreemplazable y con zstd: medido en
la oficina, el uplink da 8 Mbps iguales por cable y por wifi ⇒ 128 G no caben en una
sentada, así que sube primero el cerebro (estado + repo) y `--partial-dir` hace que cortar
a mitad de un artefacto no tire lo ya subido.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 10:24:11 -04:00

46 lines
2.4 KiB
TOML

# CPython 3.12.10 — dependencia de build del frente rust (variante b, SDD 11 §7.2b).
#
# El bootstrap de rust/LLVM corre scripts python3 (mrustc README: "python3, required for building llvm
# in rustc"). El toolchain Alpine lo trae como paquete; esta receta lo construye desde fuente para
# de-Alpinizar el camino de bootstrap de rust.
#
# python3 es una HERRAMIENTA del toolchain (corre scripts en build-time, no se enlaza en el 4/4): no
# necesita casar byte-a-byte con el de Alpine, sólo interpretar igual. Build vainilla, sin patches.
#
# CPython usa autotools (./configure). zlib viene de recipes/zlib.toml (deps.build → materialize en
# /usr); --without-ensurepip evita la red (pip), --disable-test-modules acorta el build (no se necesita
# el test-suite). Enlace dinámico: el intérprete linkea libpython/libc; estático no aporta a una
# herramienta de build-time y CPython estático es frágil. El sandbox exporta CC="zig cc -mcpu=baseline".
#
# CC=gcc/CXX=g++ (NO zig): igual que cmake, el intérprete `_bootstrap_python` compilado con `zig cc`
# SEGFAULTEA al correr (paso de "freeze modules" del build) — zig 0.16 miscompila binarios musl
# grandes (un hello-world dinámico zig sí corre; cmake y python no). Alpine compila python con gcc; el
# toolchain trae gcc/g++ nativos y funcionales en el sandbox. Es herramienta, no input del 4/4 ⇒ el
# compilador da igual mientras el intérprete corra. Con gcc, -Wdate-time ni siquiera molesta (gcc SÍ
# honra SOURCE_DATE_EPOCH para silenciarlo); se deja CFLAGS=-Wno-error=date-time por robustez.
name = "python3"
version = "3.12.10"
license = "Python-2.0"
[source]
tarball = "https://www.python.org/ftp/python/3.12.10/Python-3.12.10.tgz"
sha256 = "15d9c623abfd2165fe816ea1fb385d6ed8cf3c664661ab357f1782e3036a6dac"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
# zig 0.13.0 (NO gcc): con zig 0.14+ el intérprete `_bootstrap_python` SEGFAULTEA en "freeze modules"
# (regresión 0.14 en C/musl, misma clase que flex). 0.13.0 la esquiva ⇒ gcc deja de hacer falta.
# CFLAGS=-Wno-error=date-time se conserva: clang (zig cc) NO silencia -Wdate-time vía SOURCE_DATE_EPOCH.
zig_version = "0.13.0"
[deps]
build = ["zlib", "pkgconf"]
[build.phases]
configure = "./configure --prefix=/usr --without-ensurepip --disable-test-modules --with-ensurepip=no CFLAGS=\"-Wno-error=date-time\""
compile = "make -j\"$(nproc)\""
install = "make install DESTDIR=/out"