archlinux-s390x/patches/pkgbuild/python-packaging.sh

33 lines
1.5 KiB
Bash
Raw Normal View History

[ADD] Python packaging, through Arch's own bootstrap path 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
2026-08-21 16:37:55 -04:00
#!/usr/bin/env bash
# One of the six packages in the Python packaging cycle. The reasoning, and the
# edit, are shared -- see lib-python-bootstrap.sh.
set -euo pipefail
source "$(dirname "$0")/lib-python-bootstrap.sh"
[FIX] three packages shipped 180 unreachable module paths python-build, python-wheel and python-pyproject-hooks were built on the host, reported OK, and installed everything under usr/lib/python3/dist-packages -- Debian's name for site-packages. Our python 3.14 never looks there, so every module in them was unreachable. Nothing about them looked wrong. Their package() computes install paths from the RUNNING python: local site_packages=$(python -c "import site; print(site.getsitepackages()[0])") rm "$pkgdir/$site_packages/$_name"/*.exe which is why the other three in the same batch FAILED -- on `rm` finding nothing. Those failures were protective. All six are built by stage 2 now, where python is ours; a stage-1 run is expected to report them as failed, like libxslt. The ARTEFACT check said the repository was clean throughout, truthfully: it only ever asked about C library directories. It now also counts dist-packages and usr/local paths, so the next time this happens it says so. --- FR --- python-build, python-wheel et python-pyproject-hooks ont été bâtis sur l'hôte, déclarés OK, et ont tout installé sous usr/lib/python3/dist-packages — le nom Debian de site-packages. Notre python 3.14 n'y regarde jamais : chaque module était inatteignable. Rien en eux n'avait l'air faux. Leur package() calcule les chemins depuis le python COURANT : local site_packages=$(python -c "import site; print(site.getsitepackages()[0])") rm "$pkgdir/$site_packages/$_name"/*.exe d'où l'échec des trois autres du même lot — sur un `rm` qui ne trouvait rien. Ces échecs étaient protecteurs. Les six sont désormais bâtis par l'étage 2, où le python est le nôtre ; une passe d'étage 1 doit les déclarer en échec, comme libxslt. Le test ARTEFACT affirmait un dépôt propre, véridiquement : il n'interrogeait que les répertoires de bibliothèques C. Il compte maintenant aussi dist-packages et usr/local, pour le dire la prochaine fois. Assisted-by: Claude Opus 5
2026-08-21 16:49:37 -04:00
# The license install assumes the NON-bootstrap layout, unconditionally.
#
# install -vDm644 -t "$pkgdir/usr/share/licenses/$pkgname" \
# $srcdir/$_name-$pkgver/LICENSE*
#
# sits outside the `if (( _bootstrap == 0 ))`, but with _bootstrap=1 the source
# array is a set of git clones and there is no packaging-26.3 directory at all:
#
# install: cannot stat '.../src/packaging-26.3/LICENSE*'
#
# The clone is at $srcdir/python-packaging, and it carries LICENSE,
# LICENSE.APACHE and LICENSE.BSD. The other five PKGBUILDs handle this by
# naming a bootstrap-specific path in their else branch; this one just misses
# it, so the fix follows their shape rather than inventing one.
python3 - <<'ZZPY'
import io, re
lines = io.open("PKGBUILD", encoding="utf-8").read().split("\n")
hit = [i for i, l in enumerate(lines) if "LICENSE*" in l and "$_name-$pkgver" in l]
assert len(hit) == 1, "python-packaging: expected one license install, got %d" % len(hit)
lines[hit[0]] = lines[hit[0]].replace("$srcdir/$_name-$pkgver/LICENSE*",
"$srcdir/$pkgname/LICENSE*")
io.open("PKGBUILD", "w", encoding="utf-8").write("\n".join(lines))
ZZPY
grep -q 'srcdir/\$pkgname/LICENSE\*' PKGBUILD || {
echo "python-packaging: the license path was not redirected" >&2; exit 1; }
echo "python-packaging: license taken from the bootstrap clone"