diet-guard/packaging/aur
Krzysztof kuhy Rudnicki b3aeb4f4b7
Some checks are pending
dependency freshness / dependencies on newest stable (push) Waiting to run
file-length / file length <= 250 lines (push) Waiting to run
md-naming / markdown naming convention (push) Waiting to run
pre-commit / pre-commit (push) Waiting to run
Tests / test (push) Waiting to run
release-apk / release (APK) (push) Waiting to run
Re-point paths for the ~ reorganisation (home-tidy)
Also bumps Flutter 3.47.3, flutter_secure_storage 11.1.0, idb_shim 2.9.9,
mcp 2.2.0 and ruff 0.16.7 so the freshness gate lets this through.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AwtowrowDXx6ccmWVPkCaF
2026-09-11 19:53:03 +02:00
..
PKGBUILD packaging/aur: track the current release tag 2026-08-10 07:18:53 +02:00
README.md Re-point paths for the ~ reorganisation (home-tidy) 2026-09-11 19:53:03 +02:00

AUR packaging

PKGBUILD here is the source of truth for the diet-guard-app AUR package. The AUR checkout (~/sdk/aur/diet-guard-app) is a copy of this file plus a generated .SRCINFO.

Why the checksum can go stale

source= points at the GitHub tarball for tag v$pkgver, and sha256sums is the hash of that tarball. A tarball contains this very file, so the checksum for tag vX cannot be committed before vX is tagged. The copy here is therefore a template: after pushing a new tag, run updpkgsums in the AUR checkout to fill in the real hash, and copy the result back here.

Tagging hazard (read before tagging)

This repo has grafted upstream Flutter SDK history, so the local clone carries hundreds of tags (flutter-N.N-candidate.N, vN.N.N-N.N.pre, and a v1.16.3 that points at a 2020 [flutter_tools] commit) that do not belong to this app. The remote has only a handful.

  • Never run git push --tags here. It would publish all of them.
  • Always push one tag explicitly: git push origin v1.2.3.
  • Resolve the next free version with git ls-remote --tags origin, never with the local git tag.

v1.0.0 on the remote points at an older commit that predates the LICENSE, so the first packageable tag was v1.0.1.

Release flow

# 1. bump `version:` in app/pubspec.yaml, commit, push
# 2. tag and push the SINGLE tag
git tag v1.2.3 && git push origin v1.2.3

# 3. sync + checksum + build + verify
cp packaging/aur/PKGBUILD ~/sdk/aur/diet-guard-app/PKGBUILD
cd ~/sdk/aur/diet-guard-app
# bump pkgver to match the tag, then:
updpkgsums
makepkg -Cf
namcap ./*.pkg.tar.zst
sudo pacman -U ./diet-guard-app-*.pkg.tar.zst
diet-guard-app   # must print: diet_guard desktop serving on http://localhost:8732

# 4. publish
makepkg --printsrcinfo > .SRCINFO
git add PKGBUILD .SRCINFO && git commit && git push   # branch is `master`

Notes

  • The Flutter app lives in app/, so the tarball extracts as diet-guard-$pkgver/app/ while LICENSE sits at the repo root. build() and package() cd into the subdir; the license is installed from an absolute $srcdir path.
  • StartupWMClass is diet_guard_app (underscores) while the icon name is diet-guard-app (hyphens). They genuinely differ — the WM class must match what Chrome gets from the wrapper's --class flag.
  • install_arch.sh is deliberately not wired to this PKGBUILD. That script builds the working tree for local development; this one builds a downloaded release tarball. Merging them would destroy the dev loop.
  • options=('!strip') is load-bearing — see the comment in the PKGBUILD.
  • Building requires network access (pub get, plus a git fetch of the shared crdt_sync dependency). The tracked pubspec.lock pins what gets resolved.