nevaforget
675c8bee45
README now describes the Gitea Arch registry path as the canonical install/update mechanism — the paru --pkgbuilds fallback is no longer advertised to users. Adds troubleshooting for missing updates (check the repo DB directly) and file conflicts. DECISIONS.md records why the build-and-publish workflow now wipes all existing versions before upload, and why three packages had to be re-registered manually.
14 lines
1.8 KiB
Markdown
14 lines
1.8 KiB
Markdown
# Decisions
|
||
|
||
## 2026-04-20 – CI wipes all package versions before upload to kill DB zombies
|
||
- **Who**: Dominik, ClaudeCode
|
||
- **Why**: `paru -Syu` stopped offering `moonarch-git` updates after the r99 → r105 pkgver bump. Root cause: Gitea's Arch registry updates `moonarch.db` incrementally on upload, but does not evict old entries when a pkgver changes. `r99` lingered in the DB as a zombie — file already 404, but desc/sig still present — so clients saw `r99` as "latest" and never got `r105`. Not a one-off: every future pkgver bump would repeat the issue.
|
||
- **Tradeoffs**: Delete-before-upload adds an HTTP round-trip per package and requires `read:package` on the registry token (`write:package` was already there for upload). Alternative was an admin-side DB scrub per zombie — unscalable and hostile to the user.
|
||
- **How**: `build-and-publish.yaml` now lists every existing version of each built package via `GET /api/v1/packages/{owner}?type=arch&q={name}` and `DELETE`s them before the upload loop. jq installed on the runner as a dependency of the listing parser. The per-upload `DELETE` of the exact new version was removed (redundant).
|
||
|
||
## 2026-04-20 – Register moongreet/moonset/sweet-cursors in the Arch registry
|
||
- **Who**: Dominik, ClaudeCode
|
||
- **Why**: These three packages were missing entirely from the registry — their last pkgver-bumps landed before the `build-and-publish` CI fixes (makedepends install, source-based PKGBUILD parse, multi-artifact upload). Without a new PKGBUILD change, the workflow never re-triggered, so they stayed absent.
|
||
- **Tradeoffs**: Bumping `pkgrel` manually is a one-shot push. Alternative (wait for the next real upstream change) would have left packages uninstallable indefinitely.
|
||
- **How**: Bumped `pkgrel` in each PKGBUILD, single commit, triggered the `build-and-publish` workflow.
|