sergioandClaude Opus 5
6e27721098
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>
54 lines
2.5 KiB
TOML
54 lines
2.5 KiB
TOML
# libxml2-shared 2.13.9 — variante DINÁMICA de libxml2 para la isla dinámica de GNOME.
|
|
#
|
|
# Por qué existe, y por qué NO existía hasta ahora: en libical la libxml2 sólo la enlazaba un
|
|
# ejecutable de build (ical-glib-src-generator), así que la .a canónica alcanzó. En
|
|
# evolution-data-server NO: libxml-2.0 es dep REQUERIDA de libedataserver, libebackend, libebook y
|
|
# libecal (CMakeLists.txt:932,936,937,938), o sea que entra dentro de .so reales. La libxml2.a
|
|
# canónica no es PIC (verificado: reubicaciones R_X86_64_32) ⇒ mismo muro que sqlite y freetype.
|
|
#
|
|
# Mismo tarball, misma versión y MISMOS patches de CVE que la canónica: no se abre skew entre el
|
|
# mundo estático y el dinámico, y la superficie de seguridad es idéntica. Los .patch están copiados
|
|
# a esta cola porque se resuelven contra el base_dir de la receta, no contra recipes/.
|
|
#
|
|
# Se mantienen --without-{python,lzma,zlib} de la canónica: eds parsea XML, no comprime.
|
|
name = "libxml2-shared"
|
|
version = "2.13.9"
|
|
license = "MIT"
|
|
|
|
[source]
|
|
tarball = "https://download.gnome.org/sources/libxml2/2.13/libxml2-2.13.9.tar.xz"
|
|
sha256 = "a2c9ae7b770da34860050c309f903221c67830c86e4a7e760692b803df95143a"
|
|
patches = ["CVE-2026-6732.patch", "CVE-2026-6732-test.patch"]
|
|
|
|
[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 \
|
|
--without-python --without-lzma --without-zlib \
|
|
--with-legacy
|
|
'''
|
|
compile = 'make -j"$(nproc)"'
|
|
install = 'make DESTDIR=/out install'
|
|
|
|
[deps]
|
|
build = ["make", "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.
|