# 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
1. 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
2. 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`