Files
takana/recipes/sqlite-shared.toml
SergioandClaude Opus 5 3379a1f170 licencias: las 26 que faltaban, y el guardián que las contaba mal
CAMPAÑA CERRADA: 1166/1166 recetas declaran `license`. Ninguna adivinada — cada una sale del
fichero de licencia de su fuente PINEADA (tarball del sha256 de la receta, o el commit exacto en
la forja), y la cita queda como comentario en la propia receta.

⚠ Y EL GUARDIÁN ESTABA MAL, que es el hallazgo que vale más que las 26. `licencias-rootfs.sh`
resolvía la receta por NOMBRE DE FICHERO (`ls recipes/$pkg.toml`), y el paquete se llama por su
campo `name`, que en 34 recetas NO coincide: nu.toml→`nushell`, dust.toml→`du-dust`,
incoming-kde/qtbase.toml→`qt6-qtbase`… Medido: **14 paquetes que SÍ declaran licencia salían como
«licencia desconocida»** y el guardián vetaba una imagen perfectamente publicable.
El falso veto se nota; el hermano silencioso NO: si existe un `<pkg>.toml` que pertenece a OTRO
paquete, la versión vieja reportaba la licencia EQUIVOCADA sin decir nada. Hoy no pasa —medido,
0 casos, y de los 34 nombres duplicados CERO declaran licencias distintas—, pero ahora es
imposible en vez de improbable.

El arreglo tuvo que ser por LOS DOS lados, y el primer intento rompió el otro: el grafo de estado
nombra sus nodos por el fichero (`dust`) y el artefacto del store por `name` (`du-dust`), así que
resolver sólo por `name` dejaba a `dust` sin licencia. Ahora busca por `name` y cae al fichero.
Medido en los dos sentidos: corpus entero 1128/1128, perfil base+cli 81/81, cero sin licencia.

Y probado CON ROTURA A PROPÓSITO además del control, que es lo único que distingue a un guardián
que sirve de uno que nunca salta:
  paquete inexistente en la lista               → exit 1 y «ESTA IMAGEN NO SE PUEDE PUBLICAR»
  control (zlib nushell qt6-qtbase lsof tzdata) → exit 0, y escribe los textos
(⚠ ojo al medir: `script | tail` devuelve el exit de `tail`. La primera corrida dijo exit=0 sobre
la rotura y no era el guardián, era el pipe.)

SE LEVANTA EL VETO QUE SDD 20 DEJÓ ESCRITO. Decía que `base` y `cli` iban con 2 paquetes cada una
con binarios y licencia desconocida: `lsof` y `tzdata`, «que necesitan la vía LicenseRef- y siguen
vetando a propósito». Hechos los dos, con su texto real en licenses/:
  lsof    → LicenseRef-lsof (licencia propia de Purdue, sin identificador SPDX)
  tzdata  → LicenseRef-tz-public-domain (su LICENSE: «all files in the tz code and data … are in
            the public domain»; los tres ficheros BSD-3-Clause que menciona NO se instalan — la
            receta sólo compila zic y deja /usr/share/zoneinfo)

⚠ DOS QUE NO SE PUEDEN REDISTRIBUIR, y ahora el veto los ve:
  duplicacy    NO ES LIBRE. Su LICENSE.md: «Free for personal use or commercial trial; non-trial
               commercial use requires per-computer CLI licenses … $50 per year»
  waybackurls  NO DECLARA LICENCIA: en el commit pineado la raíz es .gitignore, README.mkd,
               go.mod, main.go y script/ — sin LICENSE ni COPYING, y el README no la menciona. Sin
               concesión expresa, el defecto es «todos los derechos reservados»
Los dos con LicenseRef y un texto en licenses/ que explica qué hay, en vez de dejar el campo vacío,
que se lee como «todavía no lo poblamos». Ninguno está hoy en un perfil de imagen; si alguien los
mete, el guardián corta.

De paso queda escrito el texto de `LicenseRef-qorpa-ajena-no-enumerable`, que ya se usaba en
steam-runtime-sniper y no tenía fichero; y `licencias-textos.sh` bajó los canónicos nuevos
(BSL-1.0 para boost, GCC-exception-3.1 que ya hacía falta).

Hueco conocido y anotado en la receta: `XFree86-1.0` (rama del OR de hwdata) se queda sin texto —
SPDX no publica ese identificador, sólo XFree86-1.1, que es otra licencia, y el tarball lo nombra
sin incluirlo. El guardián avisa y no veta, que es correcto: la otra rama del OR es la GPL y su
texto sí está.

NADA SE RE-HASHEA: `license` está fuera de `hash_inputs`. Verificado, no supuesto — `hammer hash`
sobre pigz, lsof y boost después de editarlas devuelve el hash cuyo artefacto YA está en el store.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
2026-09-09 17:47:16 +00:00

58 lines
3.5 KiB
TOML

# ── ⚠ VERRUGA MEDIDA (2026-09-05), sin decidir ─────────────────────────────────────────────────
# `usr/bin/sqlite3` —el shell de la CLI, NO `libsqlite3.so.0`— sale con `NEEDED libreadline.so.8`, y
# el `readline` canónico del corpus es `.a`. O sea que en la imagen GNOME ese comando no carga: lo
# resolvía contra el sysroot Alpine DEL LAB. Lo cazó `scripts/vigia-sonames.py`; las APPS están bien,
# porque la librería no lo lleva.
#
# Las dos salidas cuestan cosas distintas y por eso no se decide de paso:
# · construir `readline-shared` y sumarla de raíz a `escritorio-gnome` — 1 build nuevo, pero la
# imagen carga una librería más sólo para que ande un comando. (`ncurses-shared` ya es raíz del
# perfil, así que la cadena cierra.)
# · configurar acá `--disable-readline` y no instalar una CLI que nadie pidió — más limpio, pero
# re-hashea: `yupana radio sqlite-shared` da **6 dependientes en incoming-gnome** que caen a
# deuda.
# Se paga barato el día que sqlite-shared se re-selle por otro motivo.
# sqlite-shared 3.46.1 — variante DINÁMICA de sqlite para la isla dinámica de GNOME.
#
# Por qué existe: el sqlite canónico (recipes/sqlite.toml) es `--disable-shared --enable-static` y su
# libsqlite3.a NO es PIC (verificado: trae reubicaciones R_X86_64_32). libsoup 3.6 lo pide DURO
# (meson.build:123-136 cae a `dependency('sqlite3')` sin `required:false`) y libsoup es un .so ⇒
# meter el .a no-PIC adentro corta con el mismo `relocation R_X86_64_32 ... recompile with -fPIC`
# que frenó a mutter contra freetype. Mismo patrón y misma solución que zlib-shared/cairo-shared:
# una variante hermana, sin tocar la canónica (su radio son cientos de sellados).
#
# El único cambio real frente a la canónica es --enable-shared --disable-static y sacar el
# `-all-static -no-pie` de LDFLAGS, que es justo lo que impide producir un .so. Misma versión y mismo
# tarball a propósito: el sqlite3.pc que consume libsoup declara la misma versión que el resto del
# corpus, así que no se abre un skew de versiones entre el mundo estático y el dinámico.
name = "sqlite-shared"
version = "3.46.1"
# licencia: MISMO sha256 de tarball que recipes/sqlite.toml, que ya declara `blessing` (la bendición del dominio público de SQLite)
license = "blessing"
[source]
tarball = "https://sqlite.org/2024/sqlite-autoconf-3460100.tar.gz"
sha256 = "67d3fe6d268e6eaddcae3727fce58fcc8e9c53869bdd07a0c61e38ddf2965071"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
configure = "./configure --prefix=/usr --enable-shared --disable-static"
compile = 'make -j"$(nproc)"'
install = "make install DESTDIR=/out"
[deps]
# ✅ DECIDIDA 2026-09-06, y la decisión cambió porque cambió el cálculo. La verruga de arriba dejaba
# dos salidas sin elegir, y el argumento contra la primera era «la imagen carga una librería más sólo
# para que ande un comando». Ya no es cierto: `python3` sale con el MISMO `NEEDED libreadline.so.8`
# y es raíz de los cuatro perfiles, así que `readline-shared` entra en la clausura igual. El coste
# marginal de arreglar además el `sqlite3` de la CLI es CERO.
# `runtime` no entra en el ArtifactHash ⇒ no re-hashea, y los 6 dependientes que menciona la nota de
# arriba no se tocan. Esa era la otra mitad del precio y tampoco se paga.
runtime = ["readline-shared"]
build = ["make", "pkgconf"]