Principles

Similarly to AppImage, AppTar will have a tar archive, embedded in the generated executable. When the executable is run, the tar archive will be extracted in a folder in $APPTAR_TMPDIR, $TMP or /tmp with that precedence (whichever is present first). When the app exits, the temporary directory will be deleted. It is recommended that a tmpfs directory is configured.

To do that, we need a simple shell script to 'prefix' our executable, so that it becomes, well, an executable. It is written in portable shell, so it should run on any system that has the expected unix utils.

Structure

An AppTar will contain a single .tar archive, appended to a shell loader. This archive will contain app.tar, which contains your actual directory structure + some metadata files, namely .upd, .sig and .meta. All three are explained below. Furthermore, the master tar archive will have some other service files.

You most likely care about app.tar, which contains your AppRun directory, as well as your application's files.

#!/bin/sh
...loader code

(master archive)
+- app.tar
|  +- AppRun
|  +- ... other files ...
+- .upd
+- .sig
+- .meta
+- static-loader.sh

Packaging

You will need a directory which will be packaged to an AppTar. You may use the tool.sh script in this repo, or alternatively, bundle the tool with Makefile to an AppTar. The only requirement (not enforced) for AppTar-s is that they have an executable AppRun in their root.

Generating AppRun

For most applications, it is most convenient to not think about AppRun. In such cases, you may use the --entry flag, which accepts the executable, which should be templated into the built-in basic AppRun.

Update info, signature and metadata

Like AppImages, AppTars may embed update information. The format, used in AppTars does not differ from AppImages - only a single line is used to describe from where to pull the file:

• zsync|<url>
• gh-releases-zsync|<author>|<repo-name>|<tag>|<asset-wildcard>

However, AppTar defines one additional strategy: http|<url> - this instructs an updater to pull the new file from the given URL, with If-Modified-Since HTTP field set.

When using tool.sh, this can be passed either with --updinfo <line>, which specifies the update info verbatim, or --updfile <path>. Either way, if the bundled directory contains an .upd file, it will be picked up automatically.

Metadata

AppTar extends on the update and signature mechanisms by letting users embed a metadata file. This file holds no semantic meaning, it is only there so that potential package managers can display the AppTar better.

Metadata is provided with the --metafile <path> flag, and similarly to update info, if you have a .meta file in your directory's root, it is picked up automatically.

Signature

Although the runner supports blindly printing its signature file (.sig in the master tar), tool.sh currently has no capabilities of generating one, and no real effort has been made to make signatures first-class citizens of AppTars. However, it is planned.

Repackage AppImage to AppTar

If you want to make an AppTar out of an AppImage, you may extract it with --appimage-extract, and then bundle the generated squashfs-root with tool.sh. It should work in more or less the same way.

Executing

Just as simple as chmod +x-ing the AppTar image and executing it.

Permanent unpacking

Unpacking the built-in tar archive on every launch can prove inefficient. For that reason, you can either use the --apptar-install <dir> and --apptar-install-and-run <dir> options. Those options will unpack the master and app tars into the directory you chose and replace the bundle .apptar file with a static loader, that points to the specified directory.

Furthermore, if you want applications to self-install by default, you may define the APPTAR_INSTALLDIR in ~/.profile. This will make all AppTars install automatically in this folder. Doing this will make startup times of your AppTar packages significantly faster.

Compatibility

Most AppImage options have been defined, and those that haven't will throw "not implemented" errors. This means that for the user, working with an AppTar will look as if you were working with an AppImage, for the most parts.

Of course, there are some caveats: - Since fundamentally AppTars and AppImages differ in their formats, code that reads an AppImage using ELF will fail - Since AppTars use, well tar, and not SquashFS, --appimage-offset will throw an error, as to not dupe tools into reading a tar archive as if it were a squashfs image - Custom homes and config directories were deemed (by me) unnecessary, so they are left unsupported