policy(rust-pypi): release Linux wheels are manylinux_2_17, enforced by soldr wheel --release and verified — never the host's glibc floor #19

Context

The fleet policy table already says "target glibc 2.17 where feasible; verify the artifact's compatibility". It doesn't say how a release wheel gets that floor, or what counts as a violation. Migrating zackees/python-rust-build-chain to soldr wheel (#17, PR zackees/python-rust-build-chain#11) exposed the gap:

• Until now, soldr set up its glibc-2.17 toolchain only when the target differed from the host. A native x86_64 → x86_64 soldr wheel --release therefore linked the runner's glibc and was tagged manylinux_2_34+, which is honest but a silent regression. The zig path it replaced produced manylinux_2_17.
• On PyPI that changes who can install: every x86_64 Linux user with glibc older than the CI runner's is locked out, and nothing in CI flagged it.

The owner decided (zackees/soldr#3432, being implemented now) that soldr wheel --release for a *-linux-gnu target always builds against the catalogue glibc-2.17 toolchain and claims manylinux_2_17, even when target equals host. Dev builds keep the host glibc. This is the default, not an opt-in: a release wheel must never silently get the host's floor.

Proposal: policy update (docs/policy-rust.md, "Rust apps published to PyPI or npm")

1. Release wheel floor. Every release wheel for a *-linux-gnu target is manylinux_2_17, built with soldr wheel --release, which enforces the floor through soldr's 2.17 toolchain. musl targets are musllinux_1_2. A higher floor is a recorded exception with a reason, owner and review date, never an accident.
2. Verify, don't trust the tag. The release (or release-candidate) workflow checks each Linux wheel's actual glibc symbol requirements against its tag, e.g. soldr's verify_wheel_glibc.py --max-glibc 2.17. It fails the job on any mismatch or any floor above policy.
3. Where to build. Build Linux release wheels on an x86_64 Linux runner. That host produces both x86_64 and aarch64 at 2.17: aarch64 is cross-built through the catalogue. Today an aarch64 host can't produce a 2.17 wheel for either architecture (soldr#2874), so don't use ubuntu-*-arm runners for release wheels until soldr ships aarch64-hosted bundles.
4. The floor is announced, never silent.
   • When soldr wheel --release builds against glibc 2.17, it prints one green info line on stderr. The line says 2.17 / manylinux_2_17 is in use and names the command-line override (proposed --host-glibc, per soldr wheel: no runner can produce a manylinux_2_17 x86_64-unknown-linux-gnu wheel (host build is untagged-floor, aarch64 cross refused) soldr#3432).
   • Using the override is itself an exception under rule 1. It prints its own info line naming the host glibc the wheel will require.
   • CI logs must keep that line visible, so don't filter soldr's stderr.
5. Dev and PR builds are exempt. Quick-gate wheels may use the host glibc. They are for testing the installed artifact and are not published.

Checker rule (ci_lint + artifact check)

• Static:
  • flag a release workflow that builds Linux wheels without soldr wheel --release (see policy(rust-pypi): build wheels with soldr wheel (abi3-py310); ban maturin CLI and zig (--zig, maturin[zig], ziglang, cargo-zigbuild) in CI #17);
  • flag one that uploads them without a glibc verification step;
  • flag one that builds Linux release wheels on an arm64 runner.
• Artifact (release runs): inspect the uploaded wheel filenames and fail on any manylinux_2_(N>17) / linux_* tag without a recorded exception.

Acceptance criteria

• docs/policy-rust.md states rules 1–5, linking soldr wheel: no runner can produce a manylinux_2_17 x86_64-unknown-linux-gnu wheel (host build is untagged-floor, aarch64 cross refused) soldr#3432, soldr docs/API.md "Platform tags", and policy(rust-pypi): build wheels with soldr wheel (abi3-py310); ban maturin CLI and zig (--zig, maturin[zig], ziglang, cargo-zigbuild) in CI #17.
• RED → GREEN fixtures in ci_lint:
  • a release workflow uploading *-manylinux_2_34_x86_64.whl → finding;
  • *-manylinux_2_17_x86_64.manylinux2014_x86_64.whl with a verify step → none;
  • Linux release wheels built on ubuntu-24.04-arm → finding;
  • a release workflow passing --host-glibc without a recorded exception → finding.
• The inventory in chore: inventory slow PR CI and manual Soldr setup across repos #2 lists fleet repos whose latest published Linux wheels exceed 2.17.
• ci: build wheels with soldr wheel (no maturin CLI, no zig) and float soldr [blocked on soldr#3432] python-rust-build-chain#11 ships manylinux_2_17_x86_64 once soldr#3432 is released (the first conforming migration).

Decisions

• The floor is enforced by the build tool (soldr), and CI verifies it. A tag alone proves nothing: an unenforced 2.17 tag would install on old systems and crash with GLIBC_2.xx not found.
• arm64 runners are excluded for release wheels only, and only until aarch64-hosted 2.17 bundles exist. Revisit this when soldr#2874's follow-up lands.

Related

• soldr wheel: no runner can produce a manylinux_2_17 x86_64-unknown-linux-gnu wheel (host build is untagged-floor, aarch64 cross refused) soldr#3432: the tool change this policy depends on.
• policy(rust-pypi): build wheels with soldr wheel (abi3-py310); ban maturin CLI and zig (--zig, maturin[zig], ziglang, cargo-zigbuild) in CI #17: soldr wheel, no maturin CLI, no zig.
• policy(rust): avoid pinning soldr — float by default (soldr>=floor, setup-soldr@v0), exact pins only as recorded exceptions #18: avoid pinning soldr. Consumers pick up the fix by floating soldr>=….