Files
hammer/recipes/libpng-shared.toml
T
sergioandClaude Opus 5 6e27721098 sombras -shared: 8 promovidas al corpus, 0 hashes movidos — y cairo se para en un muro real
Decisión del usuario: promover una por una, verificando. Hecho así, y valió la pena.

EL RIESGO QUE SE TEMÍA NO APLICABA. La nota de `granja-promote-colisiones` advierte que
promover a ciegas hace que variantes homónimas pisen recetas canónicas. Acá no: los nombres
`*-shared` son DISTINTOS de los canónicos —`zlib-shared` no pisa a `zlib`— y se comprobó que
ninguna de las 19 sombras del catálogo choca con un nombre del corpus. Decirlo importa: repetir
una advertencia donde no aplica es tan malo como ignorarla donde sí.

VERIFICADO EMPÍRICAMENTE, no razonado: se calcularon los hashes de LAS 1153 recetas antes y
después de promover. **Ninguna cambió**, y las 8 nuevas tienen hash idéntico a su original ⇒ sus
artefactos ya están sellados y no hay que reconstruir nada. Promovidas: zlib, libpng, freetype,
fontconfig, libjpeg-turbo, libtiff, libxml2 y libyaml (todas en su variante -shared).

 `cairo-shared` NO SE PROMOVIÓ, y el porqué es el hallazgo: su hash SÍ cambia al moverla,
porque una de sus deps —`glib`— resuelve distinto desde el corpus. En `incoming-gnome-onda2`
hay una SOMBRA DE GLIB CON EL MISMO NOMBRE que la canónica (`link=dynamic`,
`-Ddefault_library=both` en vez de static), y `cairo-shared` está construida contra ella.

⇒ O sea que el riesgo de homónimos SÍ existe, pero un nivel más abajo del que se miraba: no en
las `-shared`, sino en el `glib` sombra. Promoverlo pisaría la receta canónica de glib y
re-hashearía en silencio todo lo que cuelga de ella, que es medio catálogo. El camino limpio es
renombrarla a `glib-shared` —nombre que YA existe en incoming-cosmic— y reapuntar cairo-shared;
eso cambia hashes de la cadena GNOME y merece su propia decisión, no colarla acá de madrugada.

Con esto la cadena estática del corpus (gtk4 y las 6 que cuelgan) sigue bloqueada, pero ahora se
sabe exactamente por qué y cuál es el siguiente paso concreto.

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

36 lines
1.8 KiB
TOML

# libpng-shared 1.6.58 — variante DINÁMICA (libpng16.so.16, PIC) para el escritorio KDE. El canónico
# (recipes/libpng.toml) es --disable-shared (sólo libpng16.a sin PIC) ⇒ no enlaza dentro de un .so. Como
# zlib-shared/xz-shared: autotools --enable-shared, zig-cc, contra zlib-shared (libz.so). gwenview linkea.
name = "libpng-shared"
version = "1.6.58"
license = "Libpng"
[source]
tarball = "https://downloads.sourceforge.net/libpng/libpng-1.6.58.tar.gz"
sha256 = "8c9b05b675ca7301a458df2c2e46f26e1d41ff36b8863f8c33530bc58c2e6225"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
flags = []
[build.phases]
configure = './configure --build=$CBUILD --host=$CHOST --prefix=/usr --enable-shared --disable-static CPPFLAGS=-I/usr/include LDFLAGS=-L/usr/lib'
compile = 'make -j"$(nproc)"'
install = "make DESTDIR=/out install && find /out -name '*.la' -delete"
[deps]
build = ["zlib-shared", "pkgconf"]
# ── PROMOVIDA AL CORPUS 2026-08-08 ──────────────────────────────────────────────────────────────
# Copia literal de la sombra que vivía en una cola `incoming-*`. Se promovió porque la resolución de
# deps es hermano→padre: una receta del corpus NO ve las de `incoming-*`, así que sin esto ninguna
# receta canónica puede usar las variantes dinámicas.
#
# NO hay riesgo de colisión —el que advierte la nota de `granja-promote-colisiones`— porque el nombre
# `*-shared` es DISTINTO del canónico: `zlib-shared` no pisa a `zlib`. Verificado además de forma
# empírica antes de commitear: se calcularon los hashes de LAS 1153 recetas antes y después, y
# **ninguna cambió**. El hash de esta copia es idéntico al del original, así que su artefacto ya está
# sellado y no hay que reconstruir nada.