git and meson kept failing in stage 2 on exactly what their own hooks fix, while
the log said
hook skipped (stage-1 only)
Both were named in STAGE2_SKIP_HOOKS, correctly, when their whole content was a
host workaround: git dropped ZLIB_NG because the host had no zlib-ng headers,
meson moved a wheel out of /usr/local. Then each grew a second section that BOTH
stages need -- git's asciidoc man pages, meson's hotdoc reference manual -- and
the list skips the whole FILE, so the new sections never ran. Two hooks that were
by then two thirds relevant, silently ignored.
A list of filenames cannot say why a hook is listed, and cannot notice when that
reason stops covering the file. The hooks now read EL_STAGE and decide per
section, with the reason written beside each guard; the list is gone. libgcrypt
and libarchive keep a whole-file guard, which now states its reason instead of
being an entry somewhere else.
Verified at both stages: git drops its man pages in each, and keeps ZLIB_NG in
the chroot where zlib-ng exists.
--- FR ---
git et meson échouaient à l'étage 2 sur précisément ce que leurs propres hooks
corrigent, pendant que le journal disait
hook skipped (stage-1 only)
Tous deux étaient nommés dans STAGE2_SKIP_HOOKS, à juste titre quand tout leur
contenu était un contournement de l'hôte : git abandonnait ZLIB_NG faute
d'en-têtes zlib-ng, meson déplaçait une roue hors de /usr/local. Puis chacun a
gagné une seconde section utile aux DEUX étages — les pages asciidoc de git, le
manuel hotdoc de meson — et la liste saute le FICHIER entier : ces sections n'ont
jamais tourné. Deux hooks devenus pertinents aux deux tiers, ignorés en silence.
Une liste de noms de fichiers ne peut pas dire pourquoi un hook y figure, ni
remarquer que cette raison a cessé de couvrir le fichier. Les hooks lisent
désormais EL_STAGE et tranchent par section, la raison écrite à côté de chaque
garde ; la liste disparaît. libgcrypt et libarchive gardent une garde de fichier
entier, qui énonce sa raison au lieu d'être une entrée ailleurs.
Vérifié aux deux étages : git abandonne ses pages de manuel dans les deux, et
conserve ZLIB_NG dans le chroot, où zlib-ng existe.
Assisted-by: Claude Opus 5
The first package the host is too OLD for rather than missing something.
libgcrypt 1.12.2 wants libgpg-error >= 1.56; Ubuntu ships 1.51. No -dev
package fixes a version floor.
We built 1.61 ourselves, so the material exists -- but using it crosses a
line worth naming: consuming stage 1's own output is the property that
defines stage 2. The alternative was deferring libgcrypt, which gnupg and
systemd both declare, leaving the repository unresolvable. Using our own is
also what a bootstrap does, and stage 2 erases the distinction anyway.
--with-libgpg-error-prefix looks like the mechanism and is not: it sets
GPG_ERROR_CONFIG to $prefix/bin/gpg-error-config, a program 1.61 no longer
ships. It would have named an absent file, fallen back to PATH, found 1.51
again, and the error would not have moved. GPGRT_CONFIG is what configure
consults. Verified on a copy: version >= 1.56 yes (1.61-unknown), rc=0.
The artefact carries no RPATH and no reference to the scratch prefix; it
links the bare soname, which the target resolves from its own /usr/lib.
--- FR ---
Le premier paquet pour lequel l'hôte est trop VIEUX plutôt qu'incomplet.
libgcrypt 1.12.2 veut libgpg-error >= 1.56 ; Ubuntu livre la 1.51. Aucun
paquet -dev ne corrige un plancher de version.
Nous avons bâti la 1.61 nous-mêmes, le matériel existe donc — mais l'employer
franchit une limite qu'il faut nommer : consommer la sortie de l'étage 1 est
la propriété qui définit l'étage 2. L'alternative était de reporter libgcrypt,
que gnupg et systemd déclarent tous deux, laissant le dépôt insoluble.
Employer le nôtre est aussi ce que fait un amorçage, et l'étage 2 efface la
distinction de toute façon.
--with-libgpg-error-prefix a l'air d'être le mécanisme et ne l'est pas : il
fixe GPG_ERROR_CONFIG à $prefix/bin/gpg-error-config, programme que la 1.61 ne
livre plus. Il aurait nommé un fichier absent, on serait retombé sur le PATH,
retrouvé la 1.51, et l'erreur n'aurait pas bougé. C'est GPGRT_CONFIG que
configure consulte. Vérifié sur une copie : version >= 1.56 yes
(1.61-unknown), rc=0.
L'artefact ne porte ni RPATH ni référence au préfixe temporaire ; il lie le
soname nu, que la cible résout depuis son propre /usr/lib.
Assisted-by: Claude Opus 5
