Multi-Layer AppImages

[TheAssassin]

A while ago @probonopd suggested to implement support for something I think we can call "multi-layer AppImages". They work similar to Docker images, using some sort of overlay filesystem which stacks layers on top of each other, and provides a transparent union view to the user and system.

We could implement such a feature in the new runtime. But the question is rather, do we really need that? Please feel free to leave your opinion in this issue. We don't have to discuss how it's done technically and what to be careful with*.

Please note that using multiple layers does not mean we need to ship them separately. They all need to be contained in the AppImage.

---

* For example, upper layers might remove files which have been added in lower layers. Just unioning all files doesn't provide any support for this.

[TheAssassin]

I think the main pro arguments were:

• faster builds if standard components are used
  • this might include shipping e.g., special miniconda base layers (for Python AppImages), JRE layers for Java apps or maybe Wine layers
• the base images can be signed by the upstream and provided for download

Main con arguments are:

• Potentially more bloat in the AppImage: the overhead of multiple layers' metadata is negligible, but as a user I cannot remove files I don't need from the base layer so they don't end up in the AppImage
  • might be possible to ship different base layers which contain more or less additional data, but that adds complexity
• We have not defined how to handle them, who needs to offer them and how build tools will have to handle them

Those are the ones I remember. They are not ordered by severity or anything, please evaluate them on your own.

[CosmicToast]

I don't think this is ultimately needed. The whole point of AppImage (to me, as a user and potential packager[1]) is it combines two important aspects:

• The packager has basically full control over what is inside the AppImage. The build process needs to be simple enough that the developer can be the packager, meaning that the developer has full control over what is inside the AppImage.
• Users do not need to have weird things on their systems - the fundamental UX (make executable and run) should work in basically any environment.

Having upstream-provided "layers" brings the ecosystem closer to something like flatpak, which is IMO antithetical. To be specific - bloat in the AppImage is not a concern to me (including in the runtime) so long as it serves the above two points, but the very idea of layers doesn't.

[1]: I've packaged a few things in a one-off manner but do not have any persistently built packages as of currently (abyss is only in the planning phase re: AppImages right now)

[probonopd]

Indeed I had brought this up as something that we could think about a while ago, but I am not so convinced that the benefit outweighs the complexity - especially since in many cases (Qt, Wine, Java,...) we tend to not bundle everything but only the minimal subset that is needed by a particular payload application, which greatly reduces the value of such a concept.

[TheAssassin]

I'm personally also not really convinced of this. The only significant advantage I see is a reduction of the build time of AppImages, plus the ability to use third-party stuff which can be signed. The disadvantages overweigh, though. The total amount of additional bloat cannot be neglected. And, e.g., for Python or Java, it doesn't matter too much whether I build a tool that downloads a ready-made squashfs image, or I download a tool that copies stuff into an AppDir.

Given the ability of modular AppDir creation software like linuxdeploy whose plugins take care of e.g., setting up Python (and soon Java) runtimes, multiple layers don't seem very necessary.

@5paceToast I think you got one point wrong:

Users do not need to have weird things on their systems - the fundamental UX (make executable and run) should work in basically any environment.

They do not have to have weird things on the system. As said before, the idea is to ship one or more base layers together with a user-created top layer in one AppImage file.

The packager has basically full control over what is inside the AppImage. The build process needs to be simple enough that the developer can be the packager, meaning that the developer has full control over what is inside the AppImage.

That's provided in both cases I think. You don't have to use the base layers. As we don't expect any layers to reside on the users' computers, the AppImage authors still remain in charge of what is in the AppImage. The runtime would just overlay-mount all layers providing a unified view from a temporary mountpoint.

[azubieta]

I'm currently working on something like this and is an important feature. By example, when an app is built Qt using libssl 1.0 it will not work on systems with libssl 1.1. While this is a security risk some user may still want to run their old bundle, therefore, having the right libssl version in a different (layer or partition) can allow us to pick the working one on the AppRun.

Another use case is libc, having a libc it inside the bundle in a way that could be enabled or disabled from the runtime can be useful to create portable bundles in recent systems.

So I think that having layers could be much more useful at runtime than at build time. And also agreed it adds complexity everywhere. But if the ultimate goal is to make the developers and users' life simpler I guess it's a justified complexity.

[CosmicToast]

I would opt towards simply always bundling libc, libssl and so on, and asking people to regularly update their AppImages with appimageupdatetool. If the developer doesn't want to do that though, they can also not include either.

[azubieta]

I would opt towards simply always bundling libc

If so you need to bundle everything besides the kernel and then you will find that NVIDIA graphics only work if the kernel side driver is the same version than the one in the user space. In such cases your app will crash.

[probonopd]

@azubieta be careful not to introduce dependencies other than the base system, or else you will end up with something like all the other systems out there. libssl 1.1 should have been named libssl 2.0, and should have been shipped alongside 1.0 in distributions for a while imho. But well, nobody seems to understand that. So the (really inconventient) conclusion is that one cannot rely on the one in the system, and needs to bundle it (1.1) privately.

[probonopd]

I would opt towards simply always bundling libc, libssl and so on

Depending on the complexity of the application, this might give issues when it comes to hardware-dependent features such as GPU acceleration. Although I think the Flatpak team has some patches in this area that someone would need to look into.

Keep in mind that what goes into an AppImage is not the concern of the AppImage image type; we are discussing the question of "AppImages that bundle everything" in https://github.com/AppImage/AppImageKit/issues/225. Currently I am a bit mixed on the topic, I can see pros and cons.