sergio/takana

kmod b3:7d23f879 sellada. Tres muros más, y dos son de los que se repiten:

1. `--version-script` EN DOS ARGUMENTOS. kmod/meson.build:424 pasa
   `['-Wl,--version-script', <ruta>]` como dos elementos. Con gcc + GNU ld funciona por una
   costumbre vieja (la ruta se cuela detrás como fichero de entrada y ld las asocia); el lld de zig
   ve la opción, no encuentra su parámetro y aborta con «expected parameter after --version-script».
   Se unen en la forma canónica `-Wl,--version-script,<ruta>`. El script sigue aplicándose: es lo
   que mantiene ocultos los símbolos internos de libkmod.

2. `python3` es dep de BUILD de libblockdev y de udisks aunque las bindings de Python estén
   apagadas: sus configure ejecutan AM_PATH_PYTHON igual, recorren la lista hasta `python2.0` y
   abortan con «no suitable Python interpreter found», un mensaje que no menciona ninguna opción.
   Cuarta herramienta de build que se olvida hoy, por lo mismo que las otras tres: no sale en
   ningún .pc ni en ningún NEEDED.

3. ⚠ EL ORDEN DE `[deps]` DECIDE QUÉ VERSIÓN DE blkid VE EL BUILD. `e2fsprogs` y `util-linux`
   publican LOS MISMOS FICHEROS (blkid.pc, uuid.pc, libblkid.a, libuuid.a) y la hidratación
   SOBREESCRIBE (hydrate.rs, test hydrate_overwrites_existing_without_touching_store), así que sólo
   sobrevive la del dep que se hidrata al final. Con util-linux primero, el configure veía la blkid
   1.47.4 que arrastra e2fsprogs y abortaba pidiendo >= 2.23.0. Invertido el orden gana la 2.42.2.
   e2fsprogs pide --disable-libblkid --disable-libuuid en su receta y AUN ASÍ instala las dos libs
   y sus .pc; por qué, no está determinado, y no se toca desde acá: es una receta del corpus con
   muchos consumidores. Queda escrito para que nadie reordene esa lista «por limpieza».

Y una nota de método: los dos últimos fallos fueron del latido, no del código. Su rsync --delete
desde /opt/takana revierte cualquier receta no commiteada en ≤30 min, y el build siguiente usa la
versión vieja sin avisar. La regla es commitear ANTES de construir.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

diff --git a/recipes/incoming-gnome/libblockdev.toml b/recipes/incoming-gnome/libblockdev.toml
index 0c2d84e5..ce24f7d9 100644
--- a/recipes/incoming-gnome/libblockdev.toml
+++ b/recipes/incoming-gnome/libblockdev.toml
@@ -46,13 +46,41 @@ target   = "x86_64-linux-musl"
 link     = "dynamic"
 
 [build.phases]
-configure = "CFLAGS='-O2 -fPIC' PKG_CONFIG_PATH=/usr/lib/pkgconfig ./configure --build=$CBUILD --host=$CHOST --prefix=/usr --sysconfdir=/etc --enable-shared --disable-static --disable-dependency-tracking --disable-introspection --without-gtk-doc --with-fs --with-part --with-loop --with-swap --without-btrfs --without-crypto --without-dm --without-lvm --without-mdraid --without-mpath --without-nvdimm --without-nvme --without-smart --without-smartmontools --without-s390 --without-tools --without-escrow --without-python3 && sed -i 's/ -nostdlib//g' libtool"
+configure = "CFLAGS='-O2 -fPIC' PKG_CONFIG_PATH=/usr/lib/pkgconfig ./configure --build=$CBUILD --host=$CHOST --prefix=/usr --sysconfdir=/etc --enable-shared --disable-static --disable-dependency-tracking --disable-introspection --without-gtk-doc --with-fs --with-part --with-loop --with-swap --without-btrfs --without-crypto --without-dm --without-lvm --without-lvm-dbus --without-mdraid --without-mpath --without-nvdimm --without-nvme --without-smart --without-smartmontools --without-s390 --without-tools --without-escrow --without-python3 && sed -i 's/ -nostdlib//g' libtool"
 compile   = 'make -j"$(nproc)"'
 install   = 'make DESTDIR=/out install'
 
 [deps]
 # El `sed` del `-nostdlib` va por si algún plugin arrastra C++ — es la misma trampa de libtool+zig
 # que documenta `recipes/incoming-gnome/hunspell.toml`, y ponerlo cuesta nada.
+# ⚠ `python3` es dep de BUILD aunque las bindings de Python estén APAGADAS: el `configure` de los
+# dos ejecuta `AM_PATH_PYTHON` igual y, al no encontrar intérprete, recorre toda la lista hasta
+# `python2.0` y aborta con `configure: error: no suitable Python interpreter found`. El mensaje no
+# menciona ninguna opción, así que se lee como si faltara una perilla. Cuarta herramienta de build
+# que se olvida en esta jornada, y por el mismo motivo que las otras tres: no sale en ningún `.pc`
+# ni en ningún `NEEDED` — sólo la ve el configure, fallando.
+#
+# ══ ⚠ EL ORDEN DE ESTA LISTA IMPORTA: `e2fsprogs` ANTES QUE `util-linux` ══════════════════════
+# Los dos publican LOS MISMOS FICHEROS —`blkid.pc`, `uuid.pc`, `libblkid.a`, `libuuid.a`— y la
+# hidratación de takana **sobrescribe** (`hydrate.rs`, test `hydrate_overwrites_existing_without_
+# touching_store`), así que en el sandbox sólo sobrevive UNA de las dos versiones: la del dep que se
+# hidrata al final.
+#
+# Con `util-linux` antes y `e2fsprogs` después, el configure veía la blkid VIEJA que e2fsprogs
+# arrastra y abortaba:
+#
+#     Package dependency requirement 'blkid >= 2.23.0' could not be satisfied.
+#     Package 'blkid' has version '1.47.4', required version is '>= 2.23.0'
+#
+# (`e2fsprogs` pide `--disable-libblkid --disable-libuuid` en su receta y aun así instala las dos
+# librerías y sus `.pc`; por qué, no está determinado y **no se toca desde acá** — es una receta del
+# corpus con muchos consumidores.) Invertido el orden, gana la 2.42.2 de util-linux, que es la que
+# libblockdev quiere; `ext2fs` y `e2p` son exclusivos de e2fsprogs y no chocan con nada.
+#
+# ⚠ Esto es frágil por naturaleza —un orden de lista que decide qué versión de una librería ve el
+# build— y merece arreglarse en la raíz: que `e2fsprogs` no publique lo que no es suyo. Queda
+# escrito acá para que el día que alguien reordene esta lista «por limpieza» sepa lo que rompe.
+#
 # `libudev-zero` da `libudev.pc` (el núcleo lo pide, `configure.ac:200`); `kmod` da `libkmod.pc`;
 # `util-linux` da blkid/mount/uuid; `e2fsprogs` da ext2fs/e2p; `parted` da libparted.
-build = ["make", "pkgconf", "glib", "libffi", "pcre2", "zlib-shared", "kmod", "libudev-zero", "util-linux", "e2fsprogs", "parted"]
+build = ["make", "pkgconf", "python3", "glib", "libffi", "pcre2", "zlib-shared", "kmod", "libudev-zero", "e2fsprogs", "util-linux", "parted"]
diff --git a/recipes/incoming-gnome/udisks.toml b/recipes/incoming-gnome/udisks.toml
index ef1a1830..e8466696 100644
--- a/recipes/incoming-gnome/udisks.toml
+++ b/recipes/incoming-gnome/udisks.toml
@@ -70,7 +70,14 @@ compile   = 'make -j"$(nproc)"'
 install   = 'make DESTDIR=/out install'
 
 [deps]
+# ⚠ `python3` es dep de BUILD aunque las bindings de Python estén APAGADAS: el `configure` de los
+# dos ejecuta `AM_PATH_PYTHON` igual y, al no encontrar intérprete, recorre toda la lista hasta
+# `python2.0` y aborta con `configure: error: no suitable Python interpreter found`. El mensaje no
+# menciona ninguna opción, así que se lee como si faltara una perilla. Cuarta herramienta de build
+# que se olvida en esta jornada, y por el mismo motivo que las otras tres: no sale en ningún `.pc`
+# ni en ningún `NEEDED` — sólo la ve el configure, fallando.
+#
 # `polkit` da polkit-gobject-1 Y polkit-agent-1 (las dos las pide el configure, :152 y :156).
 # `libelogind` responde al `dependency('libsystemd')` fallido (:197-208): es quien le dice a udisks
 # qué sesión está activa, que es la base de «este USB es tuyo, podés montarlo».
-build = ["make", "pkgconf", "glib", "libffi", "pcre2", "zlib-shared", "libblockdev", "kmod", "libudev-zero", "udev-pc", "libgudev", "polkit", "util-linux", "libuuid-shared", "libelogind", "parted", "e2fsprogs", "dbus", "expat"]
+build = ["make", "pkgconf", "python3", "glib", "libffi", "pcre2", "zlib-shared", "libblockdev", "kmod", "libudev-zero", "udev-pc", "libgudev", "polkit", "util-linux", "libuuid-shared", "libelogind", "parted", "e2fsprogs", "dbus", "expat"]
diff --git a/recipes/kmod.toml b/recipes/kmod.toml
index b5fd7d3a..a0647f4d 100644
--- a/recipes/kmod.toml
+++ b/recipes/kmod.toml
@@ -21,6 +21,21 @@
 # `-Dtools=true`.
 #
 # `-Dmanpages=false`: las genera con `scdoc`, que no está en el catálogo.
+#
+# ── EL `sed` DEL `--version-script`: DOS ARGUMENTOS QUE GCC UNE Y LLD NO ──────────────────────
+#     [26/33] Linking target libkmod.so.2.5.1
+#     error: expected parameter after --version-script
+#
+# `meson.build:424` pasa el script de versiones de símbolos en DOS elementos separados:
+#
+#     link_args : ['-Wl,--version-script', meson.current_source_dir() / 'libkmod/libkmod.sym']
+#
+# Con gcc + GNU ld eso funciona por una costumbre vieja: el driver le pasa `--version-script` al
+# enlazador y la ruta se cuela detrás como fichero de entrada, y ld las asocia. **El lld de zig no
+# juega a eso**: ve la opción, no encuentra su parámetro pegado, y aborta.
+# El sed las une en la forma canónica `-Wl,--version-script,<ruta>`, que es un solo argumento y no
+# depende de en qué orden acabe la línea de enlace. No cambia lo que el script hace: `libkmod.sym`
+# se sigue aplicando, que es lo que mantiene ocultos los símbolos internos de la librería.
 name    = "kmod"
 version = "34"
 license = "LGPL-2.1-or-later"
@@ -35,7 +50,7 @@ target   = "x86_64-linux-musl"
 link     = "dynamic"
 
 [build.phases]
-configure = "PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload -Ddefault_library=shared -Dtools=false -Dmanpages=false -Ddocs=false -Dbuild-tests=false -Dzstd=disabled -Dxz=disabled -Dzlib=disabled -Dopenssl=disabled -Dc_args=-Wno-error=date-time"
+configure = "sed -i \"s|'-Wl,--version-script', meson|'-Wl,--version-script,' + meson|\" meson.build && PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload -Ddefault_library=shared -Dtools=false -Dmanpages=false -Ddocs=false -Dbuild-tests=false -Dzstd=disabled -Dxz=disabled -Dzlib=disabled -Dopenssl=disabled -Dc_args=-Wno-error=date-time"
 compile   = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
 install   = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"