tarinstall

An alternative to AppImages, flatpacks and snaps to let the user install an application as a single executable file when static linking is not possible

tarinstall does not include any external files as such it does not include any man pages, example configuration files, etc. All of those have to be installed separately.

Graph

An application packaged as a tarinstall is made as such

----- Decompressor -----
|                      |
|                      |
|------- Loader -------|
|                      |
|                      |
|----- App Tarball ----|
|                      |
| app/                 |
| lib/                 |
| env                  |
|                      |
------------------------

Decompressor: It decompresses the archive and then runs the loader

Loader: It reads the env file in the tarball and enumerates the lib/ directory to loads all the necessary libraries and sets the correct environment before executing the correct binary in the app/ directory

TODO

Find a way to include external files
Include a package manager
- App binary diffs for incremental upgrades
Automated tarinstall packaging for developers
- Package manager for shared objects (libraries)
- Standardized way to define dependencies

Experimental optional components in App Tarball

ext/ directory: it includes all of the external files that have to be installed upon running the application for the first time

deps file: lists all the required dependencies and their version to allow for an empty lib/ directory at first start, all the dependencies can be downloaded upon running the application for the first time. It can also be used when packaging the tarinstall to automatically download the dependencies.

bin/ directory: it contains all other binary programs that the app may use such as POSIX utilies and shell

Advantages

Allows for application compression
Simpler and configyred in plaintext
Does not include any external dependencies other than optional ones
It can be used alongside other package managers and package formats

Compression is optional, it can be used to produce smaller packages but also increments latency wich may be unwanted.

Configuration

When the application is started the decompressor extracts the directory structure into a temporary directory in the filesystem in order to start it. This directory can be configured trough the XDG_CACHE_HOME enviroment variable and if not set it will default to /tmp/ti-<appname>, to ensure optimal performance the XDG_CACHE_HOME directory should be mounted on RAM, that said if mounted on permanent storage altough the start times will be worse, the files will only be overritten if the checksum changes so to not require the extraction everytime.

How it works

On executing the tarinstall the decompressor is executed which:
1. Calculates the cheksum of the tar application
2. It then checks the destination directory for a checksum file
3. If the calculated checksum matches the one in the checksum file it skips the extraction
4. Else it extracts the content of the tar application in the destination directory
The decompressor then executes the loader inside the destination directory which:
1. It sets environment according to the env file
2. It overrides the loader libraries with the contents of lib/
3. it enters the app/ directory and executes the binary named argv[0] with all the passed arguments

Examples

Simple example, one binary in `app/`

/home/anon/.local/bin/
	foo.ti

/bin/
	foo -> /home/anon/.local/bin/foo.ti

executing foo -h starts app/foo -h inside foo.ti

###More complex example, multiple biaries inside app/

/home/anon/.local/bin/
	foo.ti

/bin/
	foo -> /home/anon/.local/bin/foo.ti
	bar -> /home/anon/.local/bin/foo.ti
	baz -> /home/anon/.local/bin/foo.ti

executing foo -v starts app/foo -v inside foo.ti
executing bar -h starts app/bar -h inside foo.ti
executing baz -o file starts app/baz -o file inside foo.ti

4.0 KiB Raw Blame History