moonarch-pkgbuilds/DECISIONS.md
nevaforget 5fc1781262
Some checks failed
Build and publish packages / build-and-publish (push) Failing after 14m14s
fix(pkgbuild): honour CARGO_TARGET_DIR in install path
The act_runner exports CARGO_TARGET_DIR=/cache/target for cache
persistence, but the three Rust-app PKGBUILDs hardcoded
target/release/<bin>. Run 87 compiled 8 min then failed at
install stage. Use ${CARGO_TARGET_DIR:-target} so both CI and
local makepkg work.
2026-04-23 13:04:31 +02:00

38 lines
6.6 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Decisions
## 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/<bin>`. 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/<bin>"`.
## 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 ~23× 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.