Douglas Teles
b6ceea9347
Decision: pacman repo lives on GitHub Releases at archr-linux/archr-repo. No VPS, no repo.arch-r.io. Google Drive stays out of runtime (backup/archive only). Cloudflare R2 fallback deferred. Detail in docs/release-policy.md. archr-update rewritten end-to-end: - 188 lines of dead POST-to-update.arch-r.io code replaced by an 87-line wrapper around pacman -Syu. The POST endpoint never existed so there is no legacy compat to preserve. - subcommands: check, update, info. system.cfg "updates.branch" maps to repo-stable / repo-next / repo-dev tags on archr-linux/archr-repo; the mirrorlist is rewritten on every invocation so channel switches are immediate. pacman.conf rebuilt around a single [archr] repo (Arch Linux ARM upstream removed). SigLevel starts at "Required DatabaseOptional" during bootstrap; will tighten to "Required" once the production master key signs the .db. pacman-init reachability test points at github.com and the keyring populate target is "archr" instead of "archlinuxarm". archr-keyring repurposed: the three archlinuxarm keyring files are removed; package.mk now expects archr.gpg / archr-trusted / archr-revoked under keys/ and ships empty placeholders until the real ArchR master key is generated. scripts/repo/gen-pacman-repo + README: take the build.*-RK3326 tree that "make docker-RK3326" leaves behind, package each install_pkg/<x> as a .pkg.tar.zst with synthesized .PKGINFO, run repo-add to build archr.db, optionally GPG-sign everything. Emits a `gh release create` command for the publish step. CI hook left as a follow-up. docs/improvements.md 2.1 marked partial: client and build script are ready; what blocks the first usable release is generating the GPG master key, creating archr-linux/archr-repo on GitHub, and one manual publish for the repo-dev tag to validate the end-to-end loop. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
1.9 KiB
scripts/repo
Tooling for the GitHub-Releases-as-pacman-mirror workflow described in
docs/release-policy.md. The end result is a tag like repo-stable
on archr-linux/archr-repo with the assembled .pkg.tar.zst files
and signed metadata.
gen-pacman-repo
Reads the finished build tree (build.*-RK3326/install_pkg/<pkg>/)
that make docker-RK3326 leaves behind, packs each <pkg> directory
into a <pkg>-<version>-1-aarch64.pkg.tar.zst, generates the
.PKGINFO sidecar that pacman needs, and runs repo-add to build
archr.db and archr.files.
Run after a successful build:
BUILD_DIR=build.ArchR-RK3326.aarch64-2026.06-devel \
OUT_DIR=/tmp/repo-out \
CHANNEL=dev \
SIGNER= \
scripts/repo/gen-pacman-repo
Then upload:
gh release create repo-dev \
--repo archr-linux/archr-repo \
--title "ArchR repo dev $(date +%Y%m%d)" \
/tmp/repo-out/*
GPG signing
For production releases, set SIGNER=<fingerprint> and have the
agent (or a YubiKey-backed agent) ready. repo-add --sign will sign
the .db as it walks the package list, and each .pkg.tar.zst gets a
.sig as well.
The master key whose public half is bundled into the archr-keyring
package must include <fingerprint> either directly or as a signed
subkey, otherwise pacman-key --populate archr on the client will
not extend trust to packages signed by it.
Channels and tag mapping
archr-update rewrites /etc/pacman.d/mirrorlist based on
system.cfg "updates.branch":
| Channel value | Mirror tag on archr-linux/archr-repo |
|---|---|
stable (default) |
repo-stable |
next |
repo-next |
dev |
repo-dev |
The promotion workflow (dev -> next -> stable) is documented in
docs/release-policy.md.