[Feature]: Linux Installer

[MetalMan1245]

What problem does this solve?

The Linux application is portable, which is fine, but having proper desktop integration is nice.

Proposed solution

I already created the solution on my fork.

https://github.com/MetalMan1245/stemdeck

Some minor changes (namely changing paths from my fork to the upstream directories in all three installer files) would be needed to integrate this upstream but the principle is that it basically just downloads both the CPU Only and NVIDIA architectures, asks the user which one they want, puts it in either a global, local, or custom directory, installs the icon (I simply took the one you have and cropped it square for a nice desktop icon) and creates a .desktop file for easy application launching. The same solution can also be used to uninstall or upgrade to the newest version with only one line in stemdeck-install.sh needing to be updated per release.

The only thing I don't know is how this interacts with stored user data. Preferably it would be able to upgrade the application without the user's projects disappearing but I am not familiar enough with the application structure to know exactly how that would work.

Alternatives considered

The current portable application is sufficient, and while the Windows version at least appears to be portable as well, even having a simple installer (on Linux it would still be "portable" in the sense that it can still be moved, it would just break the desktop integration to do so) in my opinion is valuable, but I understand if that is contrary to your design philosophy if you want the app to remain portable with no installed version. Though I will probably try to at least somewhat maintain the installer for my own purposes if you choose not to integrate it.

[thcp]

Thanks for this! and for doing the work before asking. Yes, we want it. I went through your fork properly and ran the installer against a fake release tarball to check the assumptions rather than just read it.

Tracking the work in #360 (packaging) and #361 (the installer itself).

First, your open question

User data survives an upgrade. Stems live in ~/Documents/StemDeck/ and the runtime, models, ffmpeg and logs live in ~/.local/share/stemdeck/. Neither is inside the install directory, so removing the install cannot touch a user's projects. Your rm -rf is safe on that front.

One edge case: <install>/data/ was the old location before those moved out. A user on a very old build who has never launched a current version could still have real data there, so the installer should warn rather than delete if it sees it.

What your fork gets right

• The tarball layout assumptions are all correct, including the .NVIDIA directory name.
• The asset names match the published release assets exactly.
• The manifest-driven design is the right call. It is what makes uninstall and upgrade honest instead of guesswork.
• Global / local / custom is good UX, and ~/.config/stemdeck/ is the correct place for the manifest.
• The install path works. I ran it end to end.

The one blocker

upgrade_stemdeck removes the install directory, desktop entry, icon and manifest, and only then does install_stemdeck check whether the new archive is actually usable. I reproduced it with a truncated tarball:

==> Removing previous application...
==> Extracting archive...
tar: Error opening archive: truncated gzip input
ERROR: Failed to extract archive.

AFTER: install: GONE / desktop: GONE / manifest: GONE

A flaky download during an upgrade leaves the user with no StemDeck and no record of their custom install path. Fix is to extract and validate first, swap into place, and write the manifest last.

Three smaller ones, all reproduced

1. manifest_value is grep | head | cut under set -euo pipefail. A missing key makes grep exit 1, pipefail propagates it and set -e kills the script with no message, which also means your own "manifest may be corrupted" handler can never be reached.
2. Exec= is unquoted, so a custom path with a space in it (~/My Apps) is parsed as two arguments by the freedesktop spec and the launcher fails.
3. sort -V is not semver. It ranks 0.8.0-alpha.17 above 0.8.0, so once 0.8.0 ships, every alpha user gets told they are already up to date.

Also, "Global" sudo-installs to /opt but writes the desktop entry and icon into $HOME, so nobody else on the machine sees the app. Those should go to /usr/share/applications and /usr/share/pixmaps.

The one structural change

Ship the installer inside the tarball instead of downloading it.

This is the main difference from your version, and it removes a whole category of problems at once. make-portable.sh stages install.sh, the icon and a .desktop template into the package. Then:

• No fork or repo URLs to keep current.
• No hardcoded VERSION to bump per release. It reads backend/static/version.json from the package it is sitting in, so the installer and the build can never disagree.
• No variant prompt. The cpu-only marker file already tells it which build this is.
• No 634 MB download of both variants when the user needs 317 MB of one.
• No checksum step, because the user already got the tarball over HTTPS from the release page.

That makes stemdeck-install_remote.sh and the curl-based .desktop entry unnecessary. Dropping them also removes the unverified download, which matters here because we publish .sha256 for both tarballs and have a rule about verifying anything we fetch.

You also do not need the cropped logo. desktop/src-tauri/icons/icon.png is already square at 1024x1024, so the package can just carry that.

To your point about design philosophy: portable stays the default and the tarball must keep working when extracted and run in place. The installer is opt-in for people who want the desktop integration.

If you want to build it

The scope is in #361 and it is yours if you want it, since you said you plan to keep maintaining something like this anyway. Happy to review. If you would rather not, I will pick it up and you will be credited either way.

[thcp]

Shipped. The installer landed in #364, alongside #360 which stages the icon and the desktop-entry template inside the tarball. It will be in the next release.

I want to be straight with you about one thing: earlier in this thread I offered you the implementation, and then we built it in-house instead. That was our call, not a judgement on your work, and you deserve the reasoning rather than silence.

What we kept. The shape of your design is the shape of what shipped. Manifest-driven install state, the global/local/custom choice, and the uninstall flow reading back from the manifest are all yours. We did not arrive at those independently; we read them in your script.

What changed. Two things, one structural and one about failure handling:

• The installer now ships inside the tarball rather than downloading itself. That single change removed the version desync, the raw fork URLs, the double 317 MB download, and the unverified fetch all at once.
• Install and upgrade are atomic. The new copy is staged and verified before the existing install is touched, so the failed-upgrade case cannot strand someone with no application.

Plus the smaller ones from the review above: quoted Exec, semver-aware version comparison, manifest reads that survive a missing key, and global installs writing to /usr/share so other users on the machine can see the app.

Credit. All of it came out of reading and running your code. None of the bug list was hypothetical, each one was reproduced against your script first, and the test suite now guarding the installer is organised around exactly those cases. You will be credited in the release notes for the version that ships this. If you would rather be credited differently, or not at all, just say so.

Thanks for doing this the hard way. A fork with working code and a clear writeup of the tradeoffs is a far more useful contribution than a feature request, and it is the reason this got built at all.

[MetalMan1245]

Thank you. I didn't do this for credit so do whatever feels the most right I trust your judgement. Thank you for implementing it, I'm not upset or anything that it wasn't exactly my version or that you did it yourself, such is the nature of the open source world, help each other and share homework. I want this project to be better and if something I did facilitated that then I'm happy. I'll be looking forward to the next release with this implemented.

[thcp]

@MetalMan1245 , Just wanted to make sure that you have the recognition for contributing and again, I really appreciate you taking your time to help stemdeck to be better not only for you but for everybody else