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

57 lines
2.9 KiB
Bash
Raw Permalink 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)
[FIX] the Python bootstrap installed older code than it claimed 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
2026-08-23 23:50:06 -04:00
# BOTH LAYOUTS, because _bootstrap is now a probe rather than a constant
# (see lib-python-bootstrap.sh). With the vendored builder the sources are git
# clones under $srcdir/$pkgname; without it they are the release tarball under
# $srcdir/$_name-$pkgver. Hardcoding either one breaks the other, and the first
# version of this hook hardcoded the clone -- correct only while _bootstrap was
# always 1.
lines[hit[0]] = re.sub(
r"\$srcdir/\$_name-\$pkgver/LICENSE\*",
'"$srcdir/$pkgname"/LICENSE* "$srcdir/$_name-$pkgver"/LICENSE*',
lines[hit[0]])
# install -t with two globs would fail on whichever does not exist, so the
# whole line becomes a loop over what is actually there.
ind = re.match(r"^[ \t]*", lines[hit[0]]).group(0)
lines[hit[0]:hit[0] + 1] = [
ind + '# The sources are a git clone under $pkgname when the vendored builder',
ind + '# is used, and the release tarball otherwise. Take whichever exists.',
ind + 'for _lic in "$srcdir/$pkgname"/LICENSE* "$srcdir/$_name-$pkgver"/LICENSE*; do',
ind + ' [ -f "$_lic" ] && install -vDm644 "$_lic" -t "$pkgdir/usr/share/licenses/$pkgname"',
ind + 'done',
]
[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
io.open("PKGBUILD", "w", encoding="utf-8").write("\n".join(lines))
ZZPY
[FIX] the Python bootstrap installed older code than it claimed 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
2026-08-23 23:50:06 -04:00
grep -q 'Take whichever exists' PKGBUILD || {
echo "python-packaging: the license loop was not inserted" >&2; exit 1; }
# Matched against what is actually written -- the inserted line quotes the
# directory, `"$srcdir/$_name-$pkgver"/LICENSE*`, so a pattern expecting the
# slash to follow $pkgver directly finds nothing. The first version of this guard
# did exactly that and failed on a correct file.
grep -q '_name-\$pkgver"/LICENSE\*' PKGBUILD || {
echo "python-packaging: the tarball layout was dropped" >&2; exit 1; }
[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
echo "python-packaging: license taken from the bootstrap clone"