Package for the AUR

[vstrelnikof]

Arch users are squarely in PolterType's audience (the Wayland/Hyprland support is strongest-in-class), and "is it in the AUR?" will be the first question in any Linux thread. Nothing is published yet.

Two sensible packages, either or both welcome:

• poltertype — build from source: plain cargo build --release -p poltertype-app; the bundled wordlists live in the repo, so the build needs no network beyond crates.io. Install the binary + desktop entry + icon.
• poltertype-bin — repack the release AppImage (or extract it) for people who don't want a Rust toolchain.

Things a good PKGBUILD should handle:

• Post-install message pointing at the evdev/uinput setup: on Wayland the listener needs input-group membership + the uinput udev rule (scripts/setup-linux.sh shows exactly what's required; a package can ship the udev rule itself and print the group instruction). X11 needs none of it — worth saying, most Arch users assume the worst.
• The self-updater deliberately won't overwrite a pacman-owned file — it detects this and points at the Releases page instead. Packaged users get updates through the AUR, which is correct; no action needed, just don't be surprised.

If you'd rather maintain it under your own AUR account — perfect, that's how AUR works best; comment here and we'll link it from the README once it exists. Happy to review the PKGBUILD either way.

[vstrelnikof]

Staged in PR #17 — packaging/aur/, two packages.

poltertype builds from the release tarball: cargo build --frozen --release against the committed Cargo.lock, so it builds the dependency
versions upstream tested rather than whatever crates.io resolved this
morning. Installs the binary, the data tree at /usr/share/poltertype/data
(resolution rule 4 for a binary in /usr/bin — see
crates/poltertype-core/src/data_dir/mod.rs; get this wrong and the app
starts knowing no languages), the desktop entry, and the docs.

poltertype-bin extracts the release AppImage with
--appimage-extract, which unpacks without mounting anything — so it works
in the FUSE-less clean chroot an AUR package is supposed to build in. It
drops the libraries linuxdeploy bundled, since every one is a real Arch
package in depends() and a bundled copy shadowing the system's is how a
working app breaks three updates later.

Both ship the udev rule and the modules-load.d entry, as you suggested.
Neither adds anyone to the input group. That is a change to a user's
account, and a package making it silently has decided something on their
behalf that they did not ask for. The .install notice gives them the one
command — and warns that a login session keeps the group membership it was
created with, which is the part that actually costs people an evening.

You were right that the updater needs no special handling: it requires
$APPIMAGE to be set (an allowlist, not a list of package managers to
recognise), so it refuses a pacman-owned file by construction and points at
the Releases page. The install notice says so, so nobody files it as a bug.

packaging/README.md has the publish sequence (clone the AUR repo, copy the
directory, makepkg --printsrcinfo > .SRCINFO, namcap, push).
packaging/bump.sh <version> re-points it at a new release by hashing the
bytes GitHub actually serves. Nothing is published — that step is yours,
and needs your AUR SSH key.

.SRCINFO is deliberately not committed here: it is generated from the
PKGBUILD, only meaningful inside an AUR repo, and a stale second copy is a
way to publish a package that disagrees with its own metadata.

If you'd rather someone maintained these under their own AUR account —
that is the better outcome, and the offer in this issue still stands. These
files are a starting point, not a claim.