Retires the Arch package and replaces it with AppImage desktop integration.
Why scrap it
Never on the AUR, so installing it meant downloading a file and running pacman -U — the same gesture as chmod +x on an AppImage, for a second artifact to keep building.
It reached 1 release in 28. Only v0.4.16 has a .pkg.tar.zst; publish-arch-package.yml is workflow_dispatch-only and has run once. Meanwhile HOW-TO-USE.md told Arch/CachyOS users to download it from every release. A channel that is absent 27 times out of 28 is worse than not promising one.
It was the only packaging path with no CI coverage. Nothing validated the PKGBUILD until a manual dispatch. Removing it removes the untested surface, rather than adding a job to test something nobody installs.
Download counts are not offered as evidence — everything on every release sits at 1–2, so that data cannot decide anything.
Nothing is lost.packaging/arch/ and the workflow are preserved whole on hold/arch-packaging, the same convention the disk panel and drag-out work already use. What would make an Arch package worth having is an AUR account plus its SSH key as a repo secret — one-time manual steps that never happened, as the workflow's own header noted about its AUR push step.
What replaces it
scripts/install-appimage.sh does what a package manager's install hooks would. An AppImage carries a .desktop entry and icons inside itself, but nothing on the host ever reads them — so it never appears in the app launcher, and running it from a file manager gives a generic taskbar icon.
No sudo, nothing outside ~/.local/share, and the AppImage itself is never copied or moved.
Two details it gets right deliberately:
The Exec line is rewritten, not copied. The bundled entry says Exec=triple-c, which resolves only inside the running AppImage's own mount — copying it verbatim yields a launcher entry that appears in the menu and then starts nothing. StartupWMClassis kept as the bundle sets it, since that is what lets the shell match the window to the entry and show the real icon.
Extraction uses --appimage-extract, which needs no FUSE, so the script works on a machine where running the AppImage would first need fuse2. That requirement is now documented too — Arch and CachyOS do not ship FUSE 2 by default, which was an undocumented first-run trap.
Docs
Install table: the Arch row folds into Arch / CachyOS / other Linux → AppImage
New Adding an AppImage to the app launcher section, cross-linked to the existing App Icon Missing After Installing (Linux) note, since the shell's icon cache is the most likely "it didn't work" report
A note recording that the Arch package is gone and where it went, so the question does not get re-litigated from scratch
CLAUDE.md gains a Packaging section stating the same, with the conditions under which re-adding it would make sense
TECHNICAL.md tree updated
Verification
Tested against the real artifact — the AppImage from this repo's own preview-3a49a67 release, not a synthetic fixture:
4 icon sizes install into the correct hicolor paths
desktop-file-validate passes with no warnings (an earlier draft used Categories=Development;Utility;, which it flagged as two main categories → possible duplicate menu entries; now Development;)
--uninstall removes the entry and every icon, leaving nothing behind
shellcheck clean (an earlier draft looped over find output; now a while read loop)
scripts/scan-secrets.sh --tracked clean
No dangling references to packaging/arch, publish-arch-package, triple-c-bin or pkg.tar.zst remain outside the one intentional historical note
Not verified: that the entry actually appears in the CachyOS launcher — this container has no desktop shell, so that last step is yours.
Retires the Arch package and replaces it with AppImage desktop integration.
## Why scrap it
- **Never on the AUR**, so installing it meant downloading a file and running `pacman -U` — the same gesture as `chmod +x` on an AppImage, for a second artifact to keep building.
- **It reached 1 release in 28.** Only `v0.4.16` has a `.pkg.tar.zst`; `publish-arch-package.yml` is `workflow_dispatch`-only and has run once. Meanwhile HOW-TO-USE.md told Arch/CachyOS users to download it from *every* release. A channel that is absent 27 times out of 28 is worse than not promising one.
- **It was the only packaging path with no CI coverage.** Nothing validated the PKGBUILD until a manual dispatch. Removing it removes the untested surface, rather than adding a job to test something nobody installs.
Download counts are *not* offered as evidence — everything on every release sits at 1–2, so that data cannot decide anything.
**Nothing is lost.** `packaging/arch/` and the workflow are preserved whole on `hold/arch-packaging`, the same convention the disk panel and drag-out work already use. What would make an Arch package worth having is an AUR account plus its SSH key as a repo secret — one-time manual steps that never happened, as the workflow's own header noted about its AUR push step.
## What replaces it
`scripts/install-appimage.sh` does what a package manager's install hooks would. An AppImage carries a `.desktop` entry and icons inside itself, but nothing on the host ever reads them — so it never appears in the app launcher, and running it from a file manager gives a generic taskbar icon.
```bash
mkdir -p ~/Apps && mv ~/Downloads/Triple-C_*_amd64.AppImage ~/Apps/
./scripts/install-appimage.sh ~/Apps/Triple-C_0.4.17_amd64.AppImage
./scripts/install-appimage.sh --uninstall # to remove
```
No sudo, nothing outside `~/.local/share`, and the AppImage itself is never copied or moved.
Two details it gets right deliberately:
- **The `Exec` line is rewritten, not copied.** The bundled entry says `Exec=triple-c`, which resolves only inside the running AppImage's own mount — copying it verbatim yields a launcher entry that appears in the menu and then starts nothing. `StartupWMClass` *is* kept as the bundle sets it, since that is what lets the shell match the window to the entry and show the real icon.
- **Extraction uses `--appimage-extract`, which needs no FUSE**, so the script works on a machine where *running* the AppImage would first need `fuse2`. That requirement is now documented too — Arch and CachyOS do not ship FUSE 2 by default, which was an undocumented first-run trap.
## Docs
- Install table: the Arch row folds into `Arch / CachyOS / other Linux` → AppImage
- New **Adding an AppImage to the app launcher** section, cross-linked to the existing *App Icon Missing After Installing (Linux)* note, since the shell's icon cache is the most likely "it didn't work" report
- A note recording that the Arch package is gone and where it went, so the question does not get re-litigated from scratch
- `CLAUDE.md` gains a **Packaging** section stating the same, with the conditions under which re-adding it would make sense
- `TECHNICAL.md` tree updated
## Verification
Tested against the real artifact — the AppImage from this repo's own `preview-3a49a67` release, not a synthetic fixture:
- 4 icon sizes install into the correct hicolor paths
- `desktop-file-validate` passes with **no warnings** (an earlier draft used `Categories=Development;Utility;`, which it flagged as two main categories → possible duplicate menu entries; now `Development;`)
- `--uninstall` removes the entry and every icon, leaving nothing behind
- `shellcheck` clean (an earlier draft looped over `find` output; now a `while read` loop)
- `scripts/scan-secrets.sh --tracked` clean
- No dangling references to `packaging/arch`, `publish-arch-package`, `triple-c-bin` or `pkg.tar.zst` remain outside the one intentional historical note
Not verified: that the entry actually appears in the CachyOS launcher — this container has no desktop shell, so that last step is yours.
The `triple-c-bin` package was never on the AUR, so installing it meant
downloading a file and running `pacman -U` — the same gesture as making an
AppImage executable, for a second artifact to keep building. And being
`workflow_dispatch`-only it reached 1 release in 28 (only v0.4.16 has a
`.pkg.tar.zst`), while HOW-TO-USE.md told Arch and CachyOS users to download
it from every release. A distribution channel that is absent 27 times out of
28 is worse than not promising one.
`packaging/arch/` and `.gitea/workflows/publish-arch-package.yml` are
preserved whole on `hold/arch-packaging`, the same way the disk panel and
drag-out work were held rather than deleted. What would make an Arch package
worth having is an AUR account and its SSH key as a repo secret — both
one-time manual steps that never happened; the workflow's own header already
said as much about its AUR push step.
This also closes the gap that prompted the review: nothing validated the
PKGBUILD until someone manually dispatched the workflow, making it the only
packaging path with no CI coverage. Removing it removes the untested surface
rather than adding a job to test something nobody installs.
In its place, `scripts/install-appimage.sh` does what a package manager's
install hooks would. An AppImage carries a `.desktop` entry and icons inside
itself, but nothing on the host reads them, so it never appears in the app
launcher. The script extracts the bundled icons into the user's icon theme
and writes a launcher entry — no sudo, nothing outside `~/.local/share`, and
the AppImage itself is never copied or moved.
Two details it gets right on purpose:
* The `Exec` line is rewritten, not copied. The bundled entry says
`Exec=triple-c`, which resolves only inside the running AppImage's own
mount — a verbatim copy gives a launcher entry that starts nothing.
* Extraction uses `--appimage-extract`, which needs no FUSE, so the script
works on a machine where *running* the AppImage would first need
`fuse2` installed. That requirement is now documented too: Arch and
CachyOS do not ship FUSE 2 by default.
Verified against the real artifact — the AppImage from this repo's own
preview-3a49a67 release: 4 icon sizes install, `desktop-file-validate` passes
with no warnings, `--uninstall` leaves nothing behind, and shellcheck is
clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ApLYH6ybHwQFkMCtKuHrrV
jknapp
merged commit ed1dc8502c into main2026-08-28 20:21:02 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Retires the Arch package and replaces it with AppImage desktop integration.
Why scrap it
pacman -U— the same gesture aschmod +xon an AppImage, for a second artifact to keep building.v0.4.16has a.pkg.tar.zst;publish-arch-package.ymlisworkflow_dispatch-only and has run once. Meanwhile HOW-TO-USE.md told Arch/CachyOS users to download it from every release. A channel that is absent 27 times out of 28 is worse than not promising one.Download counts are not offered as evidence — everything on every release sits at 1–2, so that data cannot decide anything.
Nothing is lost.
packaging/arch/and the workflow are preserved whole onhold/arch-packaging, the same convention the disk panel and drag-out work already use. What would make an Arch package worth having is an AUR account plus its SSH key as a repo secret — one-time manual steps that never happened, as the workflow's own header noted about its AUR push step.What replaces it
scripts/install-appimage.shdoes what a package manager's install hooks would. An AppImage carries a.desktopentry and icons inside itself, but nothing on the host ever reads them — so it never appears in the app launcher, and running it from a file manager gives a generic taskbar icon.No sudo, nothing outside
~/.local/share, and the AppImage itself is never copied or moved.Two details it gets right deliberately:
Execline is rewritten, not copied. The bundled entry saysExec=triple-c, which resolves only inside the running AppImage's own mount — copying it verbatim yields a launcher entry that appears in the menu and then starts nothing.StartupWMClassis kept as the bundle sets it, since that is what lets the shell match the window to the entry and show the real icon.--appimage-extract, which needs no FUSE, so the script works on a machine where running the AppImage would first needfuse2. That requirement is now documented too — Arch and CachyOS do not ship FUSE 2 by default, which was an undocumented first-run trap.Docs
Arch / CachyOS / other Linux→ AppImageCLAUDE.mdgains a Packaging section stating the same, with the conditions under which re-adding it would make senseTECHNICAL.mdtree updatedVerification
Tested against the real artifact — the AppImage from this repo's own
preview-3a49a67release, not a synthetic fixture:desktop-file-validatepasses with no warnings (an earlier draft usedCategories=Development;Utility;, which it flagged as two main categories → possible duplicate menu entries; nowDevelopment;)--uninstallremoves the entry and every icon, leaving nothing behindshellcheckclean (an earlier draft looped overfindoutput; now awhile readloop)scripts/scan-secrets.sh --trackedcleanpackaging/arch,publish-arch-package,triple-c-binorpkg.tar.zstremain outside the one intentional historical noteNot verified: that the entry actually appears in the CachyOS launcher — this container has no desktop shell, so that last step is yours.
The `triple-c-bin` package was never on the AUR, so installing it meant downloading a file and running `pacman -U` — the same gesture as making an AppImage executable, for a second artifact to keep building. And being `workflow_dispatch`-only it reached 1 release in 28 (only v0.4.16 has a `.pkg.tar.zst`), while HOW-TO-USE.md told Arch and CachyOS users to download it from every release. A distribution channel that is absent 27 times out of 28 is worse than not promising one. `packaging/arch/` and `.gitea/workflows/publish-arch-package.yml` are preserved whole on `hold/arch-packaging`, the same way the disk panel and drag-out work were held rather than deleted. What would make an Arch package worth having is an AUR account and its SSH key as a repo secret — both one-time manual steps that never happened; the workflow's own header already said as much about its AUR push step. This also closes the gap that prompted the review: nothing validated the PKGBUILD until someone manually dispatched the workflow, making it the only packaging path with no CI coverage. Removing it removes the untested surface rather than adding a job to test something nobody installs. In its place, `scripts/install-appimage.sh` does what a package manager's install hooks would. An AppImage carries a `.desktop` entry and icons inside itself, but nothing on the host reads them, so it never appears in the app launcher. The script extracts the bundled icons into the user's icon theme and writes a launcher entry — no sudo, nothing outside `~/.local/share`, and the AppImage itself is never copied or moved. Two details it gets right on purpose: * The `Exec` line is rewritten, not copied. The bundled entry says `Exec=triple-c`, which resolves only inside the running AppImage's own mount — a verbatim copy gives a launcher entry that starts nothing. * Extraction uses `--appimage-extract`, which needs no FUSE, so the script works on a machine where *running* the AppImage would first need `fuse2` installed. That requirement is now documented too: Arch and CachyOS do not ship FUSE 2 by default. Verified against the real artifact — the AppImage from this repo's own preview-3a49a67 release: 4 icon sizes install, `desktop-file-validate` passes with no warnings, `--uninstall` leaves nothing behind, and shellcheck is clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ApLYH6ybHwQFkMCtKuHrrV