RELEASING.md step 3 ends with (line 19):
updatesite does not touch git, so commit the apt repo right afterwards or it drifts behind what is actually being served.
For a routine release there is nothing to commit, so following the instruction means going looking for a change that does not exist. Hit while releasing paxc 3.8.1: git status in ~/excelano-apt/ came back clean immediately after add-deb.sh -> rebuild.sh -> updatesite.
Why it is wrong
~/excelano-apt/.gitignore lists dists/ and pool/ as built artifacts, and those two directories are the only places a package add writes. What that repo actually tracks is the tooling and the shopfront: add-deb.sh, rebuild.sh, setup.sh, conf/release.conf, the keyring, the metapackage control files, and README.md. A version bump of an already-published package touches none of them.
Its history bears this out — every commit is a script or documentation change, and not one is a package version landing. The clearest case is 801c037, whose subject is "chore: prune the pool to current-plus-previous, retire three package names" and whose diff is README.md and setup.sh. The prune happened on disk and in the served repo; git recorded only the README wording that changed alongside it. That is the design working as intended.
The first half of the sentence is correct and worth keeping: updatesite is an rsync and does not touch git. The conclusion drawn from it is what does not follow.
Replacement
updatesite is an rsync and does not touch git, but a routine package add leaves nothing to commit either — dists/ and pool/ are gitignored build artifacts. Commit the apt repo only when you changed something tracked: a script, conf/release.conf, a metapackage control file, or the README's curated install hint.
What is not affected
Only that one trailing sentence. The rest of step 3 is right and should not be touched — in particular the --delete dry-run warning above it is load-bearing, since the apt pool is a superset of live.
The question the wrong sentence was reaching for — which package versions are actually live — is real but is not answerable from git, and should not be. Read it off the served repo: the Packages file under dists/, or apt-cache policy against the live URL. Tracking dists/ and pool/ to close that gap would mean committing signed binaries on every release.
Fleet-wide
The same sentence is in six runbooks, so it was written once and copied forward before the wording was tested: paxc, ved, nved, xql, xfiles, blick-cli. xled, xray and xshape carry the updatesite step without it. Found and fixed first in excelano/paxc#21; this issue is the same finding filed against this repo, since it is a different session's lane.
RELEASING.mdstep 3 ends with (line 19):For a routine release there is nothing to commit, so following the instruction means going looking for a change that does not exist. Hit while releasing paxc 3.8.1:
git statusin~/excelano-apt/came back clean immediately afteradd-deb.sh->rebuild.sh->updatesite.Why it is wrong
~/excelano-apt/.gitignorelistsdists/andpool/as built artifacts, and those two directories are the only places a package add writes. What that repo actually tracks is the tooling and the shopfront:add-deb.sh,rebuild.sh,setup.sh,conf/release.conf, the keyring, the metapackagecontrolfiles, andREADME.md. A version bump of an already-published package touches none of them.Its history bears this out — every commit is a script or documentation change, and not one is a package version landing. The clearest case is
801c037, whose subject is "chore: prune the pool to current-plus-previous, retire three package names" and whose diff isREADME.mdandsetup.sh. The prune happened on disk and in the served repo; git recorded only the README wording that changed alongside it. That is the design working as intended.The first half of the sentence is correct and worth keeping:
updatesiteis an rsync and does not touch git. The conclusion drawn from it is what does not follow.Replacement
What is not affected
Only that one trailing sentence. The rest of step 3 is right and should not be touched — in particular the
--deletedry-run warning above it is load-bearing, since the apt pool is a superset of live.The question the wrong sentence was reaching for — which package versions are actually live — is real but is not answerable from git, and should not be. Read it off the served repo: the
Packagesfile underdists/, orapt-cache policyagainst the live URL. Trackingdists/andpool/to close that gap would mean committing signed binaries on every release.Fleet-wide
The same sentence is in six runbooks, so it was written once and copied forward before the wording was tested:
paxc,ved,nved,xql,xfiles,blick-cli.xled,xrayandxshapecarry theupdatesitestep without it. Found and fixed first in excelano/paxc#21; this issue is the same finding filed against this repo, since it is a different session's lane.