-
-
Notifications
You must be signed in to change notification settings - Fork 563
Brainstorming
This page is for brainstorming about a hypothetical type-3 image format that may be introduced at some distant point in the future. Currently there are no current plans yet since this is in the very early requirements gathering stage, and we don't want to bring out new image types frequently (since this always causes a lot of work for everyone). So we'd rather like to take all the time to get the next format "right".
- Consider the claims made in https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-format/9466 and think about how the situation can be improved
Investigate and decide on using zstandard
Investigate and decide on using zip instead of squashfs, proof of concept: https://github.com/orivej/static-appimage
Investigate and decide on using statically linked runtime, proof of concept: https://github.com/orivej/static-appimage
- Chunking and hashing with knowledge of the content. Same algorithm should be used for both Delta updating and P2P distribution for the sake of simplicity and code reuse. May well need a filesystem that is specifically optimized for this
- Make it easier to extract metadata and data needed for system integration. E.g., only allow png as .DirIcon, disallow svg, disallow symlinks, etc.
- Is there a container format that could be extracted by unarchiving tools, and that could still be a valid AppImage at the same time?
- Can we provide an easier way to determine the offset at which the filesystem image starts, without having to parse ELF? E.g., wrap everything in something like
.ar? - Can we embed the .zsync file somewhere before the filesystem image starts? This way, we would need only one file on the server rather than two
Currently we are using "reserved" bits which does not work in all cases, e.g., the interpreter (/lib/ld-linux.so.2) gets confused by this in some cases (e.g., sometimes in Docker containers or VMs or on some niche Linux distros), yielding a "no such file or directory" error message (overwriting the magic bytes with zeroes is a suitable workaround).
There should be a minimal runtime specification to separate the runtime from the contents of an AppImage and the handling. It should only but completely define the structure and behavior of an AppImage compliant spec.
The specification should be versioned using a monotonically increasing version number, ensuring backwards compliance, ideally with tools.
This will allow for writing runtimes in different languages, and automating testing of compliance with the specification. It should be investigated whether it's possible to automate such a compliance verification by writing the definition in some special language or markup. Such tools exist for algorithms, so there might be some for files and programs as well. If not, we should write an ecosystem allowing for such tests, which will also be useful to other people developing runtimes.
The reference runtime can be included in the same repository, but should indeed be separated from tools like appimagetool. There is a need for building a proper runtime distribution for appimagetool etc., as we never had any real system for this. Any appimagetool build should be able to build AppImages for any architecture, however right now we only included one runtime for one architecture in appimagetool that was used automatically.