Multi-arch AppImages

Developers
1

In the AppImage docs, it mentions that multi-arch AppImages are not possible due to Linux not supporting FatELF or similar. Such a feature can be added by making the AppImage runtime in a well-supported interpreted language, such as POSIX shell script. I have a functional project that demonstrates this feature https://github.com/mgord9518/shappimage.

It could add a bit of convenience primarily for small apps or anything already built on interpreters.

2 Likes
2

Sounds pretty awesome! This would polish the software distribution experience quite a bit: developers would no longer be forced to offer 32bit, 64bit and ARM download links, and users would no longer need to know what architecture each one of their devices is running

Couple of questions:

  • Doesn’t any file explorer have trouble running shImg packages by double clicking on them? I seem to remember that a few years back some of them detected the file started as a shell script and asked whether to run it or open it in a text editor, instead of just running it
  • Doesn’t it work with fuse2? What fuse3 feature does it need? I think fuse3 still doesn’t come installed by default on many systems
3

I’m not sure about Nautilus, but Dolphin gives options to either execute or open it in a text editor (assuming it’s marked executable). .run files have been distributed for a very long time and unfortunately they’re still not recognized correctly by most file managers. A new mime definition could of course solve this by grouping them with AppImages, but I find it unlikely this would ever be adopted in mainstream distros.

The fuse2 vs fuse3 issue is tricky as fuse3 for some reason breaks compatibility, giving the choice between supporting older distros with fuse2 and newer with fuse3, but not both. I could probably use a patched version of fuse like the standard AppImage implementation just started doing, I need to look into it further.

The format is still pretty experimental, my goal currently is getting them to 100% compatibility parity with the standard implementation, which to my knowledge should just be using the patched fuse, then patching the squashfuse binary to allow for extraction without fuse

4

When I had experimented with interpreted languages over a decade ago, double-clicking such AppImages would sometimes result in text editors opening the AppImages rather than the AppImages executing. Has this improved nowadays?

5

Not that I know of, if anything it may have gotten worse. KDE is alright with them (gives option to execute or edit), which is what I use but I think GNOME always opens in a text editor. XFCE and LXQt both behave the same as KDE to my knowledge.

I’d like to see if adding a custom MIME would change the behavior, but the odds GNOME will play nice with them is practically nil as they seem to be pushing further away from supporting executing things from Nautilus instead of making it better.

Idk what the solution is besides just having to execute it through the shell