shadow-testandClaude Sonnet 5
e025a7441a
Part of triple-c#34's third ask ("I would like to also have an
Arch/CachyOS native version as well"), addressed separately from the
Wayland crash fix (fix/wayland-webkit-egl-crash) since it's an unrelated
feature, not a bug.
packaging/arch/PKGBUILD is a "-bin" AUR package repackaging the same .deb
build-app.yml already produces — no Rust/Node toolchain needed to install
it, and the user gets exactly the binary the project ships and tests.
Verified end to end against a real release (v0.4.14) rather than going by
Tauri's generic docs: downloaded the actual .deb, ldd'd the actual binary
to ground-truth `depends` (dropped `pango` and `libayatana-appindicator`
from an earlier draft — the first is already pulled in transitively by
gtk3, the second was never linked at all since this app has no tray icon
or menu), and ran a real makepkg/namcap/pacman -U cycle. namcap caught a
real issue this way (missing license file under
/usr/share/licenses/triple-c-bin/), now fixed by fetching LICENSE
alongside the .deb.
.gitea/workflows/publish-aur-package.yml does the actual publishing:
given a version (or "latest"), it finds that release's real Linux asset
on GitHub, downloads it, computes real checksums, renders the PKGBUILD
template, validates the result with makepkg and namcap inside a real
Arch container, and pushes to AUR. workflow_dispatch only, deliberately —
the same reasoning that killed sync-release.yml in triple-c#32 (releases
are assembled by build-app.yml across three separate platform jobs, so
there's no single automatic event that fires only once the Linux .deb
this needs actually exists) applies here too.
Requires a repo secret this workflow cannot set up itself:
AUR_SSH_PRIVATE_KEY, from an AUR account that has already created (or
been given co-maintainer access to) triple-c-bin — both one-time manual
steps on aur.archlinux.org. Until that secret exists, the workflow fails
loudly at the push step rather than silently doing nothing. See
packaging/arch/README.md for the full maintenance flow.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2.4 KiB
Arch / CachyOS package
PKGBUILD here is the AUR triple-c-bin package's template — see triple-c#34
(the "I would like to also have an Arch/CachyOS native version" part of it).
Why "-bin"
It repackages the same .deb build-app.yml already produces, rather than
building from source. That means makepkg never needs a Rust toolchain,
Node, or the dozen -dev packages CLAUDE.md lists for building Triple-C
itself — and a user gets exactly the binary the project ships and tests,
built on Ubuntu 24.04 in CI. Verified end to end against a real release
(v0.4.14): downloaded the actual .deb, confirmed every depends entry
against a real ldd of the actual binary (two packages that looked right
from Tauri's own docs — pango, libayatana-appindicator — turned out not
to be real dependencies of this binary and were dropped), and ran a real
makepkg/namcap/pacman -U cycle rather than guessing at the shape.
Publishing
.gitea/workflows/publish-aur-package.yml does the actual work: given a
version (or "latest" if none is given), it finds that release's real Linux
asset on GitHub, downloads it, computes real checksums, renders this
template into a version-specific PKGBUILD, validates it with makepkg and
namcap inside a real Arch container, and pushes the result to AUR.
It is workflow_dispatch-only, deliberately — see the workflow file's own
header comment for why an automatic trigger isn't safe here (the same reason
sync-release.yml didn't work and was removed in triple-c#32).
Before it can push anything, an AUR account has to exist and the
triple-c-bin package has to have been created (or you added as a
co-maintainer) under it — both are one-time, manual steps on
https://aur.archlinux.org, since there's no API to automate creating an
account or a new package. Once that's done, add the account's SSH private
key as the AUR_SSH_PRIVATE_KEY secret on this repo. Until that secret
exists, the workflow fails at the "Push to AUR" step with a message saying
so, rather than silently doing nothing.
What's hand-maintained vs. generated
pkgver/pkgrel/source/sha256sums in this file are placeholders —
the workflow rewrites them for every real publish and never commits the
result back here, so don't read this file's pkgver as "the last published
version." Everything else (depends, pkgdesc, package()) is meant to be
edited by hand normally, the same as any other PKGBUILD.