add type3 spec

[Samueru-sama]

I saw TheAssassin made this repo but nothing has been added, so instead of waiting here is my two cents of what a type3 AppImage must be.

Note: This is all already supported by the uruntime minus the ARG0 change which is something I want to get upstreamed first.

Rationale behind some of these changes:

---

• The mountpoint SHOULD be a unique hash of the AppImage and not random every time.

The reason is that this allows reusing already running AppImages instead of creating multiple mountpoints which wastes resources. Fixes AppImage/AppImageKit#1100

By making it a hash of the AppImage we avoid any possible conflict with other AppImages and make sure the mounpoint is reused by the same application only.

---

• MUST set the following enviroment variables:
  • APPIMAGE Which points to the location of the AppImage with symlinks followed
  • ARG0 Which points to the location of the AppImage without following symlinks
  • OWD Path to the working directory when the AppImage was executed

The reason I have changed ARGV0 for ARG0 is becasue ARGV0 causes a ton of problems with zsh to the point that I've seen projects code workarounds for this in their code instead of just unsetting the variable manually in the AppRun which that on its own is a terrible hack.

Even I that I'm aware of this problem have been bitten by it multiple times, the most recent one was this, which was fixed previously...

---

• The AppImage MUST also preserve the original values of HOME, XDG_DATA_HOME, XDG_CONFIG_HOME and XDG_CACHE_HOME by setting the following envrioment variables:
  * REAL_HOME To the value of HOME before chaging it
  * REAL_XDG_DATA_HOME To the value of XDG_DATA_HOME before chaging it
  * REAL_XDG_CONFIG_HOME To the value of XDG_CONFIG_HOME before changing it
  * REAL_XDG_CACHA_HOME To the value of XDG_CACHE_HOME before changing it
  • If the REAL_* enviroment variables are already set, the AppImage MUST NOT change their value
  • If XDG enviroment variables are empty, the AppImage MUST set the REAL_* variables to the defaults specificed in the XDG Base directory specification

By keeping the original values of these enviroment variables, the application can restore them before executing child processes. This fixes the issue of other apps using the portable directories of the AppImage.

Since the uruntime does this already, we have this xdg-open wrapper with all of our sharun AppImages that restores the enviroment variables. For applications like terminal emulators I preload a library that does the same.

snap also does something similar already btw

---

Now onto things I don't think need to be changed.

I don't think it is a good idea to mandate a specific filesystem or compression algo, because maybe in 5 years from now some new format that is much better comes out and we are not able to use it.

Instead it is better to mandate specific flags into the AppImage runtime, that way tools like libappimage can instead falllback to using --appimage-extract for example, and this can be done easily in a sandbox

This is also why --appimage-extract must extract to an AppDir directory instead of squashfs-root, since the filesystem may be completely different, the AppImage can instead make a squashfs-root symlink to keep compatiblity with existing scripts/tools that expect a squashfs-root directory.

I also don't think we need to change the magic bytes, since most of these changes do not break backwards compatibility with existing tools, for example appimageupdatetool has no problem updating an AppImage that follows this type3 spec.

[probonopd]

This requires a more detailed discussion. Just some key points:

• We do need to move the magic bytes since the current location is known to cause real life issues (blame me for choosing the current location, which turns out to be suboptimal)
• We do not want to adopt even more from XDG/fd.o - to the contrary, I'd like to decrease the use of XDG/fd.o specs, which I consider to be inelegant
• Sooner or later (in 3 or 4) we will want to specify the exact filesystem/compression, in order to allow e.g., libraries and tools to extract files without having to execute AppImages

[Samueru-sama]

• We do need to move the magic bytes since the current location is known to cause real life issues (blame me for choosing the current location, which turns out to be suboptimal)

What are the issues exactly?

We do not want to adopt even more from XDG/fd.o - to the contrary, I'd like to decrease the use of XDG/fd.o specs, which I consider to be inelegant

You already set XDG_CONFIG_HOME and HOME in the type2-runtime, this change just adds the rest of variables and preserves them.

I also don't know what you mean by "being inelegant", thanks to variables like XDG_DATA_DIRS you don't have a ton of applications hardcoded to look into /usr/share and are easy to package as result.

Sooner or later (in 3 or 4) we will want to specify the exact filesystem/compression, in order to allow e.g., libraries and tools to extract files without having to execute AppImages

Alright but not adding fallback to --appimage-extract and not mandating the flag sounds like a terrible idea.