So what's current thinking on Linux packaging? I want to ship a standalone GUI application for Linux.
There are tools for building a Linux AppImage, but they're kind of old. AppImageKit was last updated in 2020, and it never made it into a Ubuntu distro.There's "cargo appimage", which is current, but needs some version of "appimagetool" from AppImageKit.
Snaps are Canonical's thing to force devs to use their "app store". They're at war with Flatpaks, and Flatpak support is being removed from Ubuntu. So, probably best not to go there.
Or should I just go back to good old "download and unzip"?
Does cargo-dist work yet? The documentation says: The current version is Experimental and the extra conveniences currently only work with Github CI and Github Releases. From the documentation, it's all tied closely to Github.
Their idea of an "installer" is piping curl into a shell. Mine is an application for end users. Remember them? "Command line? What's that?"
cargo appimage is supposed to do the job, with a hint or two in the Cargo.toml file. It's one of those things that makes an executable file which bootstraps itself into a mounted mini file system. It has hidden assumptions about where files are supposed to be and what they are supposed to be named. Those assumptions aren't well matched to Cargo layout and Rust standards. When you finally execute the running program, it's called "bin", it's in usr/bin/bin in its own file system, and your asset files are in "../../ASSETFILENAME". Input files have to be in the root directory of the project, and the output is put there as well, not somewhere under target. I got the error message "os error 2 - file not found", with no filename, for not having something in the expected place. Little of this is documented.
cargo appimage requires installing appimagetool. Appimagetool comes, of course, as an .AppImage file, but cargo appimage does not know this. So appimagetool has to be downloaded, installed, and renamed to work. Also, appimage is not in the repositories for Ubuntu, which kind of means it's out of the mainstream.
You can bash this thing into working, but these tools are of far lower quality than the rest of the Rust ecosystem.