Feature appimages as well

[Zughy]

Problem

We ship no appimages

Solutions

Both @ronoaldo (https://github.com/ronoaldo/minetestclient) and @rollerozxa (https://forum.luanti.org/viewtopic.php?t=31136) are shipping Luanti appimages. How about integrating their work in the official repo? I don't know whose

Alternatives

Don't

Additional context

No response

[wsor4035]

@rollerozxa would you be willing to pr your workflow from https://github.com/rollerozxa/luanti-appimage/blob/master/.github/workflows/build.yml ?

[farooqkz]

It's a very good addition. We had a LibrePlanet LAN party a while ago. Internet access was very limited and almost unusable in the building. So I did a HTTP server in LAN for APKs, EXEs and AppImages. If AppImages become official, it will be really good. Also it would be very good if we had AppImages for aarch64 also. Could be very useful for SBCs.

[rollerozxa]

@rollerozxa would you be willing to pr your workflow from https://github.com/rollerozxa/luanti-appimage/blob/master/.github/workflows/build.yml ?

Yes, I can do that sometime soon. I've been meaning to do that once SDL2 support became stabilised anyway.

In addition to the scripts to build and create an AppImage, I also bundle a version of SDL that's much newer and better configured than Debian's SDL (Debian configures SDL so that all library linkage is explicit rather than dynamically loaded depending on what exists on the system, which is terrible for portability). I piggyback off of the SDL builds we do for Principia AppImages here https://github.com/principia-game/linux-deps, but for official inclusion it's probably good to make a copy of this repo under the luanti-org org.

Also it would be very good if we had AppImages for aarch64 also

Should be simple now that GitHub Actions has hosted ARM runners, was going to do that for my AppImage builds but haven't gotten around to it yet.

[rollerozxa]

As for the technical differences between my AppImage builds and ronoaldo's, I'll just dump some thoughts:

Mine uses appimagetool directly and is a lot lower level, while his uses AppImageBuilder which works on top of appimagetool.

My analysis of the dependency tree to figure out what libraries that are bundled are quite thought out from testing on stripped down Linux distros and have left out a lot of things that are evergreen libraries that could always be expected on a graphical Linux system (libcurl, zlib, freetype, etc.), while AppImageBuilder tries to bundle as much as possible. The compromise is basically the size of the resulting AppImage versus how well it will work on any system you put it on, however if you bundle certain core system libraries it could also break for that reason, so it's a precarious balance.

I believe AppImageBuilder bundles glibc somehow which should make it portable across older distros and musl distros, but I've never actually gotten this to work myself (a common occurrence with AppImages, perhaps). My AppImages get built on Debian 11 Bullseye which means it will work on any distro newer than that (glibc 2.31 and newer), which is still pretty wide encompassing.

[sfan5]

Has AppImage fixed that problem where it won't run on distros that ship FUSE 3 but not 2? Portability is a joke otherwise.

[HybridDog]

I think with zlib-ng instead of zlib, PNG image decompression is significantly faster, so bundling zlib-ng instead of zlib in the AppImage or using an external zlib-ng may benefit the performance.

[ronoaldo]

Has AppImage fixed that problem where it won't run on distros that ship FUSE 3 but not 2? Portability is a joke otherwise.

That is a very good point. It turns out, my builds utilize an "old" version of the AppImage runtime. A newer runtime is available and this one has some static linked stuff that no longer needs libfuse2. I did a test changing my scripts to use linuxdeploy instead of appimage-build and it looks like this fixed it. I could run the AppImage in a fresh install of Ubuntu 22.04 without any additional steps. The build was done on Debian 12 via Docker.

If I understood correctly, the builds from @rollerozxa utilize a newer runtime already (by leverating the low level appimagetool directly), so that is a bonus point!

Fuse not being availble at all (i.e. the kernel does not have it) requires the file to be unpacked directly instead by the user (with --appimge-extract). I recall that at some point in the past AppImage used a loopback mount instead, and an ISO (CD) filesystem, but I have no idea why that changed...

I'll watch this issue and as soon as it has been merged I may redirect my scripts into this one. Another goal of my scripts is to attempt to rebuild specific versions, i.e., allow to selectively build a revision, commit or tag. I may keep that work as of now. If this type of work is useful, the script can by used by the project CI or to make easier to test regressions.

Side note: as @rollerozxa mentioned, the bigger the binary the more "portable", but it is a trade-off. Bundling optimized deps looks a good compromise to me for a portable version for Linux, but whenever the project members see works. Having AppImage as an alternative download can be handy for some situations where adding the whole Flatpak runtime is not feasible.