python-packaging's PKGBUILD says pkgver=26.3 and the installed module reported
25.0. The vendored builder selected by _bootstrap=1 carries its OWN copy of each
project, older than the release the PKGBUILD names. Nothing about the package
looked wrong; only `packaging.__version__` disagreed with its own name, and the
mismatch surfaced two packages later:
python-vcs-versioning: packaging>=26.2
a floor our own package met on paper and not in fact.
_bootstrap is now a probe evaluated by makepkg, in the build environment: if
`build` and `installer` import, the real path works and the vendored copies are
not wanted. A hook could not decide this -- hooks run on the HOST even for stage
2, so a probe written there cannot answer for the chroot.
The license install then had to handle both layouts, since the source tree is a
git clone under $pkgname when bootstrapping and a release tarball otherwise.
Hardcoding either breaks the other, and this hook had hardcoded the clone -- right
only while _bootstrap was always 1.
--- FR ---
Le PKGBUILD de python-packaging annonce pkgver=26.3 et le module installé
rapportait 25.0. Le constructeur embarqué que sélectionne _bootstrap=1 porte ses
PROPRES copies de chaque projet, plus anciennes que la version nommée. Rien dans
le paquet n'avait l'air faux ; seul `packaging.__version__` contredisait son
propre nom, et l'écart est apparu deux paquets plus loin :
python-vcs-versioning: packaging>=26.2
un plancher que notre paquet satisfaisait sur le papier et non en fait.
_bootstrap est désormais une sonde évaluée par makepkg, dans l'environnement de
construction : si `build` et `installer` s'importent, la voie normale fonctionne et
les copies embarquées ne sont pas voulues. Un hook ne pouvait pas trancher — les
hooks tournent sur l'HÔTE même pour l'étage 2, donc une sonde écrite là ne peut
pas répondre pour le chroot.
L'installation de la licence devait alors gérer les deux dispositions, l'arbre
source étant un clone git sous $pkgname en mode bootstrap et une archive sinon.
Écrire l'une en dur casse l'autre, et ce hook avait écrit le clone en dur — juste
seulement tant que _bootstrap valait toujours 1.
Assisted-by: Claude Opus 5
Three stage-2 builds -- brotli, libseccomp, meson -- stopped on
/usr/bin/python: No module named build
and building python-build means running `python -m build`. Its dependencies are
the same cycle: packaging and pyproject-hooks are flit_core-backed, installing a
wheel wants python-installer, and none of the six exist yet.
On the host the cycle was already broken -- apt had python3-build -- so stage 1
never met it. Breaking it there again is not possible: apt has no
python3-flit-core at all, so the backend all six need cannot be installed on the
host by any means.
Arch had already solved it, in the PKGBUILDs: `_bootstrap=1` selects a vendored
builder that needs none of the six. That is upstream's supported path through
exactly this situation, and it replaced a half-written alternative here -- three
bespoke hooks calling `python -m flit_core.wheel` and unzipping into $pkgdir --
which would have reimplemented what the PKGBUILD already does properly.
--- FR ---
Trois constructions d'étage 2 — brotli, libseccomp, meson — se sont arrêtées sur
/usr/bin/python: No module named build
et bâtir python-build suppose d'exécuter `python -m build`. Ses dépendances sont
le même cycle : packaging et pyproject-hooks passent par flit_core, installer une
roue demande python-installer, et aucun des six n'existe encore.
Sur l'hôte le cycle était déjà rompu — apt fournissait python3-build — donc
l'étage 1 ne l'a jamais rencontré. Le rompre à nouveau là est impossible : apt
n'a aucun python3-flit-core, donc le moteur dont les six ont besoin ne peut être
installé sur l'hôte par aucun moyen.
Arch l'avait déjà résolu, dans les PKGBUILD : `_bootstrap=1` sélectionne un
constructeur embarqué qui n'a besoin d'aucun des six. C'est la voie prévue en
amont pour exactement cette situation, et elle a remplacé une solution
à demi écrite ici — trois hooks sur mesure appelant `python -m flit_core.wheel`
puis dézippant dans $pkgdir — qui aurait réimplémenté ce que le PKGBUILD fait
déjà correctement.
Assisted-by: Claude Opus 5
