feat(ci): add a targeted per-R-minor rebuild workflow #198
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/rebuild-abi-gap"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
A user hit this on amd64/resolute under R 4.6.1:
R 4.6 no longer exports
SETLENGTH:base64enccallsSETLENGTH(base64.c:206,253), its flat binary was built under R 4.4.3, and it has no per-minor copy at all, so the union index hands that binary to a 4.6 client.The safety net missed it because the risky set is defined circularly:
A package counts as ABI-risky only if it has already been built per-minor.
base64encnever was, and having no new CRAN version it never enters the build list to be classified. So the per-minor protection only covers packages that passed through the pipeline after the scheme existed.Scope
Scanning all 4,585 compiled binaries in amd64/resolute's flat index for symbols R 4.6 does not export found 10 referencing
SETLENGTH. Most already have per-minor builds and are served correctly. Two do not:(
iotoolslacks a 4.5 copy but 4.5 still exportsSETLENGTH, so it does not break.)What this adds
Rebuilding one package into one minor was only possible with
just rebuildfrom a workstation holding the S3 and Postgres credentials. This adds the CI path:reindex.yaml's slot matrix verbatim, so the slot-to-image mapping cannot driftbuild-one.R --sensitive-only, which reclassifies each version and skips anything not ABI-risky rather than writing it to the wrong slotcrow lintpasses.Not in this PR
This is the remediation path, not the fix. The circular
risky_packages_across_minors()definition is still in place, so new instances of this class can still appear. That is the follow-up.