Rebuild reprepro's database from the pool before publishing

[guys-inc-ops]

Excluding db/ from the bucket was the right call — earlier runs served reprepro's working state publicly. But it reintroduced, by another route, exactly the failure #33 was written to prevent.

The problem

reprepro export writes dists/ from the database, not from the pool. db/ is the one thing the state pull cannot bring back, so every run starts with an empty database and regenerates the indexes from only the packages it included itself.

Today that is invisible, which is why it survived review — all three architectures ship in one run, and reprepro keeps one version per package anyway, so the output is correct by coincidence rather than by construction. I verified that: a persisted db and a lost db produce identical output for the current flow. Nothing is broken right now.

It stops being correct the moment a run publishes a subset — one architecture failing to build, a re-publish of a single asset, or a second package in the repo. Measured in a debian:bookworm container, publishing both arches at 3.4.9 and then amd64 alone at 3.4.10:

run 1: publish both arches at 3.4.9      index: amd64=3.4.9  arm64=3.4.9
run 2, db LOST (today):  amd64 3.4.10    index: amd64=3.4.10 arm64=<empty>
run 2, db KEPT (control): amd64 3.4.10   index: amd64=3.4.10 arm64=3.4.9

arm64 users lose the package and the run stays green.

The fix

Reconstruct the database from what the bucket already holds, before including anything new. Verified rather than assumed:

• reprepro exits 0 and skips a package it already has (Skipping inclusion … as it has already '2.0'), so a re-publish of the same tag stays idempotent — confirmed by running the same tag twice: exit 0, index and pool unchanged.
• Including a deb from the pool does not delete the file it is reading. I checked this specifically, because reprepro does print Deleting files just added to the pool but not used in the superseded case.
• It also fixes a smaller live problem: superseded pool objects are currently never removed, because nothing knows they exist. With the rebuild, github-desktop_3.4.9_amd64.deb is cleaned up when 3.4.10 supersedes it.

Running the two new steps verbatim against the failure scenario:

===== WITHOUT the fix =====        ===== WITH the fix =====
amd64: 1 listed, 2 in pool         restored 3 package(s) from the pool
arm64: 0 listed, 1 in pool         amd64: 1 listed, 1 in pool
armhf: 0 listed, 1 in pool         arm64: 1 listed, 1 in pool
guard exit=1                       armhf: 1 listed, 1 in pool
                                   guard exit=0

The guard

The second step is the one that would have caught this. An empty index is a valid, correctly signed index — indistinguishable downstream from a repository that genuinely has no packages — so the check has to happen here, while the pool is still around to compare against.

Worth flagging: my first version of that guard was broken and passed the very case it exists to catch. grep -c prints 0 and exits 1 on a zero-match file, so the || echo 0 fallback produced "0\n0" and the comparison silently stopped working. Caught by running the step against the real failure rather than trusting it. Now: exit 1 with two ::error:: lines on the bug, exit 0 clean on a healthy repo.