CI/AppImage: Use fuse3 compatible appimagetool

[Samueru-sama]

Uses this appimagetool: https://github.com/probonopd/go-appimage

Fixes a common issue with libfuse2 not being installed by default in newer distros as it can use libfuse3 instead. (It also works if only libfuse2 is installed as well just in case).

I'm sorry for the VERSION=test hack I did there, this appimagetool needs that variable as it uses it to add the version to the title of the appimage. Normally that would be the output of ./*AppDir/AppRun --version but it seems duckstation doesn't support that flag.

EDIT: Artifact if needed: https://github.com/Samueru-sama/duckstation/actions/runs/9899316061/artifacts/1693128006

This appimagetool also uses zstd compression, which results in a slightly smaller appimage.

---

Btw go-appimage can also do the job of linuxdeploy and it has a deploy everything mode, which makes the appimage be able to work everywhere including in much older distros and musl distros at the cost of increasing the size of the appimage by ~40 MiB edit actually it may be about 10 MiB lol

[stenzek]

Btw go-appimage can also do the job of linuxdeploy and it has a deploy everything mode, which makes the appimage be able to work everywhere including in much older distros and musl distros

I wouldn't be opposed to this, but I would be concerned about other host libraries breaking due to older library versions. e.g. a graphics driver depending on a symbol in newer libwayland/libc/etc; this has been a problem in the past with AppImages.

[Samueru-sama]

Btw go-appimage can also do the job of linuxdeploy and it has a deploy everything mode, which makes the appimage be able to work everywhere including in much older distros and musl distros

I wouldn't be opposed to this, but I would be concerned about other host libraries breaking due to older library versions. e.g. a graphics driver depending on a symbol in newer libwayland/libc/etc; this has been a problem in the past with AppImages.

Pardon my ignorance, but wouldn't this be prevented by building on a recent version of glibc? since it would get bundled there is no problem in choosing a more recent distro to build on.

[stenzek]

Sure, I suppose, but rolling release distros tend to be ahead of the LTS versions on the GitHub runners, so we may need a container... The irritating part would be when these distros do update, and then all of a sudden a previously-working binary stops running.

Definitely something worth looking into though :)