Package as AppImage

[mgord9518]

Hello, as The Powder Toy is already being packaged in a portable format I'd like to suggest adding AppImage as an alternative download for Linux.

I have a build script available which could either be used as is or as a packaging reference.

AppImages are compressed out of the box and are meant to bridge the gap between unstandardized portable applications and fully integrated native applications. Packaging officially as an AppImage would give the benefits of the desktop integration info being accessible by AppImage integration software, a small download with no need to extract, automatic thumbnailing (like Windows EXE files) in supported desktops such as KDE, and the trust that comes along with it being an official package as opposed to a 3rd party build.

I'd be happy to answer any questions about it or assist in tweaking the build script if need be, thanks in advance!

[LBPHacker]

We'll be looking into this. I may have questions later, but right now the appimage concept is too new to me to have any.

[LBPHacker]

So how are appimages supposed to bundle their security library of choice (openssl in the official build's case) and still have it somehow find e.g. root CAs on the host system?

[mgord9518]

Most AppImages aren't completely self contained. In the case of this AppImage build of TPT, it statically links all of the same libraries as the official build and requires the system to have some dynamic libs present (this link is a list of libraries which can reasonably be expected to exist on any desktop Linux system)

I'm not exactly sure how openssl looks for its certs, I just assumed it was just hardcoded to /etc and /usr/share. Compatibility-wise, the AppImage is identical to the official build

[mgord9518]

@LBPHacker any updates on this yet?

[LBPHacker]

@mgord9518 Nope, none. I haven't had time recently to work on anything TPT related that takes more than 15 minutes to handle :/

[Firestar-Reimu]

I think this binary is good, why AppImage? They do the same thing.

[mgord9518]

@Firestar-Reimu AppImages contain desktop integration information so that people using AppImage software (such as AppImage launcher) will have the executable seamlessly integrate like a native app. Another advantage (for people not using any AppImage software) is that there's no reason to unzip it, it just quickly uncompresses at runtime.

I think the binary is good and I'm not at all suggesting it gets replaced with an AppImage, I just think the addition would be good for the people who do prefer it.

[LBPHacker]

And I agree. See above, but I'll try to keep this in mind.

[LBPHacker]

@mgord9518 I saw chdir being mentioned in a not exactly appreciative way in AppImage documentation, so I'm wondering whether what we do right now is acceptable: checking if there's a powder.pref in cwd, and if not, chdiring away to SDL_GetPrefPath(NULL, "The Powder Toy").

[mgord9518]

@LBPHacker can you link to the documentation?

Assuming SDL_GetPrefPath is the XDG data home, I believe that's handled pretty perfectly.

[LBPHacker]

I meant this particular page, ^F chdir. And yes, I realize that chdir is mentioned in a context that doesn't make it relevant for us, but it still felt like something that might not be optimal to do, yet I couldn't find anything else on it elsewhere in the doc.

Anyway, yes, it seems SDL does it right.

[mgord9518]

@LBPHacker I believe it's just saying it would be a problem for patching an application that was designed to be installed into /usr.

As for The Powder Toy, which is already designed to be used portably, it doesn't need to be patched at all.

[LBPHacker]

This is currently blocked by the openssl (and really any other security lib) situation being a joke on linux, see

• Detect when included into AppImage; root CA and engines path openssl/openssl#7481
• https://gitlab.com/probono/platformissues/blob/master/README.md

[mgord9518]

@LBPHacker Isn't this also an issue with normal binary distribution?

[LBPHacker]

It indeed is.

[LBPHacker]

This is currently blocked by the openssl (and really any other security lib) situation being a joke on linux, [...]

For the record, I consider this issue unblocked (as unblocked as it'll ever be anyway) by 09c2704.

[mgord9518]

@LBPHacker what's that mean as far as distribution as an AppImage goes?

[LBPHacker]

It means I now feel comfortable planning an appimage release.

The changes that needed to happen for this were bundling a TLS library (I ended up with mbedtls because it's smaller lol) and adding a way to set the CA file / directory options from within TPT, which beats having to fiddle with obscure environment variables that the TLS library may or may not respect.

This issue is on the 97.0 project; expect an appimage release when 97.0 lands.

[LBPHacker]

@mgord9518 How is the AppImage in this run?

[mgord9518]

@LBPHacker It works on my Ubuntu 22 machine, the only usability issue I was able to find is that it prompts for an install (and if you do then the desktop files are broken because AppImage mounts at a random temporary location)

Assuming that it works on other distros, I'd just use the "-Dignore_updates=true -Dinstall_check=false" build flags for TPT as AppImage has a system for updates, then add some update information to it using the "-u [UPDATE INFO]" flag with appimagetool. The update information string will probably be along the lines of "gh-releases-zsync|The-Powder-Toy|The-Powder-Toy|continuous|Powder_Toy-*$ARCH.AppImage.zsync"

I'm not really sure how it would work without a continuous build tag though. Of course, update information is also something that can just be added later down the line

[LBPHacker]

Yeah I forgot about those flags :| I was kinda hoping to get away without creating a separate job for appimage builds, or separate debug info for them, but oh well.

[LBPHacker]

I think I'll leave update information out for now. We'll probably store the zsyncs on our update servers, but I guess github releases are not a bad idea either. This requires further thought. Until then, 1f7b01b.

[Firestar-Reimu]

for now, it needs fuse2:

dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information

[LBPHacker]

This is an AppImage requirement that we have no control over :|

[mgord9518]

@Firestar-Reimu AppImage currently has an experimental 100% static runtime that doesn't require anything except the fusermount binary installed on the system (which all mainstream desktop Linux distros do)

Once it goes upstream then any system with either FUSE2 or FUSE3 will work