# Decisions ## 2026-04-28 – Bump epoch on moongreet-git after upstream version rollback - **Who**: Dominik, ClaudeCode - **Why**: `pacman -Syu` warned that local `moongreet-git 0.10.0.r0.gce9f219-3` is "newer" than the moonarch registry's `0.8.6.r0.gb9b6f50-1`. Cause: `greetd-moongreet` upstream was tagged `v0.9.0` and `v0.10.0` early on, then the tag history continued with `v0.8.4` → `v0.8.5` → `v0.8.6` patches on top — a deliberate downgrade of the version line. `pkgver()` uses `git describe --long --tags`, which now returns `0.8.6.r0.gb9b6f50` at HEAD, but any system that built moongreet before the tag rollback still has the higher-sorting `0.10.0` installed. Without an epoch bump, those systems will never accept the registry's 0.8.x as an upgrade. - **Tradeoffs**: Re-tagging upstream to leapfrog past v0.10.0 (e.g. v0.11.0) would also resolve the mismatch and avoid the epoch — but it would create a fake version that doesn't reflect the actual feature scope, and we'd be permanently chasing the v0.10.0 ghost on every future bump. Epoch is the canonical pacman mechanism for exactly this situation; one-time cost, no upstream lie. - **How**: `epoch=1` added to `moongreet-git/PKGBUILD`, `pkgrel` bumped 3 → 4 to retrigger CI. ## 2026-04-28 – Bump epoch on sweet-cursors-git to overrule AUR-built local installs - **Who**: Dominik, ClaudeCode - **Why**: `pacman -Syu` warned that local `sweet-cursors-git r445.1d92ac7-1` is "newer" than the moonarch registry's `r1.4b49c35-2`. Cause: our Gitea fork (`nevaforget/Sweet-cursors`) is a one-shot snapshot of `EliverLara/Sweet`'s `kde/cursors/Sweet-cursors/` from 2025-09-28 with a single `init` commit, so `pkgver()` always evaluates to `r1`. The local r445 came from the AUR package by `Gigas002` (source: `github.com/Gigas002/Sweet#cursors`, 445 commits, actively maintained, last cursor change 2026-03-02). Without an epoch bump, vercmp would flag the registry as a downgrade on every system that ever installed via paru/AUR. - **Tradeoffs**: Switching the PKGBUILD source to `Gigas002/Sweet#cursors` would track upstream and avoid the version mismatch entirely, but requires `inkscape` + `xorg-xcursorgen` makedeps and a non-trivial SVG-compile build step in CI. Cursor changes upstream are minimal in practice (one fix in 6 months), so the maintenance value is low. Keeping the snapshot keeps the build trivial and the source tiny — at the cost of being permanently frozen at the September 2025 state. Documented in the fork's README. - **How**: `epoch=1` added to `sweet-cursors-git/PKGBUILD`, `pkgrel` bumped 2 → 3 to retrigger CI. Added `README.md` to the `nevaforget/Sweet-cursors` Gitea repo explaining the snapshot rationale and pointing to `Gigas002/Sweet` for users who want a maintained variant. ## 2026-04-23 – Rust PKGBUILDs honour CARGO_TARGET_DIR - **Who**: Dominik, ClaudeCode - **Why**: The act_runner container sets `CARGO_TARGET_DIR=/cache/target` (for cross-build cache persistence), but `moongreet-git`/`moonlock-git`/`moonset-git` `package()` hardcoded `target/release/`. Run 87 compiled for 8 min and then failed at `install: cannot stat 'target/release/moongreet'` because the binary actually lived in `/cache/target/release/`. Silent until today because earlier builds pre-date the env var. - **Tradeoffs**: None meaningful — the fallback `${CARGO_TARGET_DIR:-target}` preserves local `makepkg` builds (no env var → still reads from `./target/`). - **How**: Patched `install -Dm755` in all three Rust-app PKGBUILDs to use `"${CARGO_TARGET_DIR:-target}/release/"`. ## 2026-04-23 – Single-threaded, low-priority build in CI to keep the Gitea host alive - **Who**: Dominik, ClaudeCode - **Why**: The act_runner container shares CPU/RAM/I/O with the Gitea host (network-host mode, no resource limits). Parallel Rust builds OOM-kill or thrash the host: run 86 (2026-04-23, moongreet-git 0.8.3.r1) stopped mid-compile at `Compiling gio v0.22.2` with no error, and gitea HTTPS was unreachable for ~11 min. Same pattern on 2026-04-20. Runner-side resource limits would be better, but require host-side config changes; a pipeline-side fix is portable and low-risk. - **Tradeoffs**: Builds are slower — single-threaded cargo compile of a moon* project takes ~2–3× as long. `nice -n 19` + `ionice -c 3` further delay the build when the host is busy, but that's the point. Slow build beats downed host. - **How**: `build-and-publish.yaml` exports `CARGO_BUILD_JOBS=1` and `MAKEFLAGS=-j1` before `makepkg`, and wraps `makepkg` with `nice -n 19 ionice -c 3`. Affects every package build in the matrix. ## 2026-04-21 – moonarch-git becomes a full meta-package (hard deps on all Arch-repo essentials + own registry siblings) - **Who**: Dominik, ClaudeCode - **Why**: `moonarch-git` listed `moongreet-git`/`moonlock-git`/`moonset-git` only as `optdepends` and omitted most Arch-repo essentials (wlsunset, networkmanager, bluez, xwayland-satellite, file-manager stack, zsh plugins, CLI tools, …) entirely — they lived only in `packages/official.txt`. `paru -S moonarch-git` on a fresh system therefore produced a desktop with no greeter, no lockscreen, no power menu, no nightlight, no network manager, no portals — a non-functional Moonarch. Split source of truth between PKGBUILD deps and txt files caused continuous drift (e.g. walker-bin was missing from both). - **Tradeoffs**: `moonarch-git` is now chunky — installing it pulls ~60 packages (vs ~20 before). Acceptable because this is exactly what every Moonarch system needs; a leaner package just shifted the install work to imperative scripts that silently failed. AUR packages cannot be hard `depends=` (pacman can't resolve AUR), so they stay in `packages/aur.txt` and post-install.sh pulls them explicitly. `optdepends=` was slashed to real extras (docker, rustup for dev, waterfox) — no more mirroring of aur.txt there. - **How**: Added to `depends=`: moongreet-git, moonlock-git, moonset-git, xwayland-satellite, libnotify, foot-terminfo, wlsunset, nwg-look, awww, libpulse, gst-plugin-pipewire, networkmanager + nm-applet + nm-openvpn + openvpn, bluez, gvfs + gvfs-{dnssd,mtp,smb}, udisks2, ntfs-3g, xdg-desktop-portal-{gnome,gtk}, qt6-5compat, zsh-{autosuggestions,syntax-highlighting}, bat, btop, eza, fastfetch, fd, fzf, lazygit, ripgrep, neovim, git, fwupd, ufw. Removed from `optdepends=`: all Moonarch ecosystem packages (now hard deps), all AUR packages (post-install.sh pulls from aur.txt), and already-depended Arch-repo packages. `pkgrel` bumped 9 → 10. ## 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.