Packaging: offer Markpad on the AUR (markpad-bin) — official or community?

[LargeModGames]

Proposal: offer Markpad on the AUR

Splitting this out from #498 as a packaging question rather than a bug.

Why

The Linux AppImage is the fragile channel: it bundles the graphics stack and breaks on hosts with a newer Mesa (the WebKitGTK pin in #463, and the libwayland-client bundling in #498). The .deb/.rpm do not have this problem, because they depend on the host libwebkit2gtk-4.1 instead of bundling it.

For Arch-family users the natural install path is the AUR, and it structurally avoids the whole bundled-graphics failure mode for the same reason the .deb does. The original reporter in #182 is on CachyOS (Arch family), so this is exactly the audience that would benefit.

What I have

I have already written and locally validated (makepkg) a markpad-bin PKGBUILD that repackages the official .deb:

• depends=('webkit2gtk-4.1' 'gtk3' 'hicolor-icon-theme') (host WebKitGTK, so no EGL bug)
• unpacks the .deb payload verbatim: usr/bin/Markpad, the .desktop entry, and the hicolor icons
• installs the BSD-3-Clause LICENSE and README

Name note: the plain markpad on the AUR is an unrelated project (Twilight0/MarkPad), so this would be markpad-bin to avoid the collision.

The actual question: official or community?

• Community (lowest effort for you): I publish and maintain markpad-bin on my own AUR account and keep it current with each release. No burden on this repo; you would optionally just link it from the README.
• Official (upstream-driven): automate AUR updates from CI. That needs an AUR account you own plus AUR_SSH_PRIVATE_KEY / AUR_USERNAME / AUR_EMAIL secrets in a repo you control. I am a contributor here, so I cannot add those secrets to this repo, which is why I am asking rather than just opening a PR.

How I do this for my own project (spotatui), as a template

I maintain two AUR packages for spotatui and keep them in sync from the upstream repo automatically:

• https://aur.archlinux.org/packages/spotatui (builds from source)
• https://aur.archlinux.org/packages/spotatui-bin (repackages the release artifact)

A publish-aur.yml GitHub Action (workflow_dispatch) does the update: it curls the release artifacts to compute their sha256, sed-bumps pkgver/pkgrel/checksums in the PKGBUILD, regenerates .SRCINFO by running makepkg --printsrcinfo inside an archlinux:latest container, and pushes to the AUR over SSH. I am happy to replicate that setup for Markpad, in whichever repo makes sense given the secret constraint above.

Ask

1. Do you want an official AUR presence, or are you happy for me to maintain markpad-bin as a community package and link it from the README?
2. Any preference between a source-build package and the .deb-repackage -bin approach? (I would suggest -bin first: it reuses the signed release build and is the most reliable.)

Happy to open the follow-up (publish the package, and/or wire the workflow) once you decide the direction.

[PathGao]

This is a well-scoped proposal, and splitting it out of #498 was the right call — a packaging question and a graphics bug do not belong in one thread. You have also already done the part that usually stalls these: a PKGBUILD that exists and has been validated locally, plus an offer to keep it current, which is the expensive half.

Two things that might help the decision get made.

The community option is unblocked right now. It needs nothing from this repository, so it does not have to wait on this thread at all — and if the goal is that the CachyOS reporter in #182 has a working install path, that path can exist before any of the rest is settled. A README link can follow whenever, or not.

The official option is worth weighing on something other than upkeep. AUR_SSH_PRIVATE_KEY, AUR_USERNAME and AUR_EMAIL would live in the same repository as TAURI_SIGNING_PRIVATE_KEY, and possibly in the same job. RELEASING.md §4 records that the signing key has no revocation path — if it is ever compromised, a new keypair has to be generated and every user reinstalls by hand. #499 is a smaller instance of the same question. That does not make it a bad idea; it just means the thing to weigh is what stands next to that key, and that is @alecdotdev's call rather than a purely technical one.

For my own part, so nobody is left waiting on a review that would not be much good: I work on cross-platform defects, macOS and some Windows. I have no Linux hardware, so I could not evaluate a PKGBUILD honestly — I would just be adding a step. On the evidence of #463 and #498, Linux going directly between you and @alecdotdev is a better arrangement than routing it through me, and I am glad it is in hands that can actually run it.