nevaforget
b4ee733827
All checks were successful
Build and publish packages / build-and-publish (push) Successful in 12s
The moonarch.install hook used to ensure /etc/paru.conf had Mode = arp and a [moonarch-pkgbuilds] section. Both exist to let paru resolve moonarch packages from a PKGBUILD repo — a second mechanism parallel to the Arch registry, redundant now that the registry DB is stable. Hook now strips the legacy config on next upgrade. Bump pkgrel so every installed system picks up the cleanup.
20 lines
2.9 KiB
Markdown
20 lines
2.9 KiB
Markdown
# Decisions
|
||
|
||
## 2026-04-20 – Registry is the only install path; drop paru --pkgbuilds
|
||
- **Who**: Dominik, ClaudeCode
|
||
- **Why**: Two parallel mechanisms for finding moonarch packages (the Arch registry via `[moonarch]` in `pacman.conf`, and paru's PKGBUILD-repo via `[moonarch-pkgbuilds]` in `paru.conf`) created ambiguous state: `paru -S` resolves from whichever has a matching version first, and diagnostics have to account for both. With the registry DB now stable (see zombie fix below), the PKGBUILD-repo path is redundant.
|
||
- **Tradeoffs**: No more local-build fallback when the registry is broken — but when the registry is broken, the real fix is to repair it, not to mask the problem with a second mechanism. Existing systems need their `/etc/paru.conf` cleaned once (hook handles that on next moonarch-git upgrade).
|
||
- **How**: `moonarch.install` post_install now deletes `Mode = arp` and the `[moonarch-pkgbuilds]` section from `/etc/paru.conf` instead of writing them. `moonarch/scripts/post-install.sh` and `transform.sh` no longer configure paru.conf or call `paru -Syu --pkgbuilds`; they run `pacman -Sy` + `paru -S moonarch-git` (registry only).
|
||
|
||
## 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.
|