[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

patches/pkgbuild/python-packaging.sh

@@ -3,3 +3,30 @@
 # edit, are shared -- see lib-python-bootstrap.sh.
 set -euo pipefail
 source "$(dirname "$0")/lib-python-bootstrap.sh"
+
+# 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"

scripts/packages.sh

@@ -243,6 +243,12 @@ STAGE1_PACKAGES=(
     # and python-tqdm installs one. On the host these came from apt; in the
     # chroot they have to be packages. Ordered by their own dependencies:
     # flit-core bootstraps itself, then the two libraries build needs.
+    # Of these seven, only python-flit-core builds on the host. The other six
+    # compute their install paths from the running python, so the host bakes
+    # Debian's dist-packages into them -- three failed on a `rm` that found
+    # nothing, and three succeeded and shipped 180 unreachable module paths.
+    # They are built by stage 2 instead; a stage-1 run is expected to report
+    # them as failed, exactly like libxslt.
     python-flit-core
     python-packaging
     python-pyproject-hooks

scripts/test-chroot.sh

@@ -117,8 +117,27 @@ for f in "$REPO"/*.pkg.tar.*; do
     [ "$c" -gt 0 ] && { bad "$(basename "$f"): $c multiarch paths"; n=$((n + 1)); }
     c=$(grep -c '^usr/lib64/' <<< "$_l")
     [ "$c" -gt 0 ] && { bad "$(basename "$f"): $c paths under usr/lib64"; n=$((n + 1)); }
+    # dist-packages: Debian's name for site-packages.
+    #
+    # Added after three packages were built, declared OK, and shipped
+    # usr/lib/python3/dist-packages -- python-build, python-wheel and
+    # python-pyproject-hooks. Our python looks in
+    # /usr/lib/python3.14/site-packages, so every module in them was
+    # unreachable. This check said the repository was clean the whole time,
+    # because it was only ever asked about C library directories.
+    #
+    # What makes it worth a permanent check rather than a one-time fix: the
+    # three packages that FAILED in the same batch failed on `rm` not finding a
+    # path, which is what saved them from shipping the same way. Nothing about
+    # the three that succeeded looked wrong.
+    c=$(grep -c 'dist-packages/' <<< "$_l")
+    [ "$c" -gt 0 ] && { bad "$(basename "$f"): $c paths under dist-packages"; n=$((n + 1)); }
+    # usr/local: python's posix_local scheme, and anything else that took the
+    # host's idea of where a local install goes.
+    c=$(grep -c '^usr/local/' <<< "$_l")
+    [ "$c" -gt 0 ] && { bad "$(basename "$f"): $c paths under usr/local"; n=$((n + 1)); }
 done
-[ "$n" -eq 0 ] && good "every library is under usr/lib -- no multiarch, no lib64"
+[ "$n" -eq 0 ] && good "no multiarch, no lib64, no dist-packages, no usr/local"
 
 note "3. SONAME -- what binaries ask for versus what the repository ships"
 # Two passes over the packages: collect the soname each shared library