nevaforget/moonarch-pkgbuilds
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
moonarch-pkgbuilds/DECISIONS.md
nevaforget b4ee733827
All checks were successful
Build and publish packages / build-and-publish (push) Successful in 12s
Details
feat(install): drop paru --pkgbuilds fallback, registry is the only path 
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.
2026-04-20 14:19:01 +02:00

2.9 KiB
Raw Blame History

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 DELETEs 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.