Slimpack

A pragmatic and minimalistic repacker of flatpak applications without (much) isolation.

Why?

Some might be big proponents of the whole isolation thing, but I believe that linux is in the unique position where isolation doesn't really work on the desktop. Why? Because to have isolation, you need to have a way to talk to the outside world. On phones, this happens trough well-established APIs that the vendors provide the programmers, because of which isolation on mobile works. However, on linux, there isn't really a standardized set of APIs to do desktop apps. You have KDE and Gnome's takes on them, but no one unified standard. This of course means that if we ever wish to containerize, we need to create APIs for KDE, Gnome and whatever comes next.

Flatpak's take on this conundrum, of course, is as dreadful as possible - not only are they not solving the issues, they refuse to recognize that there's an issue at all! Furthermore, the tooling around flatpak is simply, and without any doubt, a whole new level of terrible.

However, flatpak did one thing - it convinced a lot of developers they were the only place you should be publishing your apps. This means that flathub is one of, if not the most valuable assets to the linux desktop ecosystem. If only we could run those apps like any sane person would - natively...

This is where this project comes in. Slimpack aims to be a small tool that allows you to repackage a flatpak package into a self-contained executable, that runs pretty much natively. No longer do you have to fiddle with flatseal for 2 hours just to run a darn electron app.

Why not?

This project is VERY experimental, employing a custom filesystem, which has bricked my whole OS I/O, until I restart. You are expected to know what you're doing, and even if you do, expect stuff to go south.

How?

Since the flagship flatpak client needs to download the apps from a repository, we can do that too. In short, this project implements a simple OSTree client (without all the BS the flagship client comes with) that can successfully list the remote refs (apps) and download any given app (and its metadata).

The other big part of the project is the actual repacking of the app. In short, each app has dependencies and a specific runtime it demands to be present. The original flatpak client will 1. download the runtime (for all intents and purposes a distro) and 2. download all the dependencies it has. This client in stark contrast will only download the dependencies and will assume that the libraries, packaged by flatpak's runtimes are present on the host.

When this program repacks a flatpak, it will get put in a self-contained executable as a squashfs image. When the executable gets run, the application will get run in a VERY light container, which only layers the squashfs on top of the container (unfortunately, using the currently employed methods, there are some limitations, but everything that ran under flatpak should run here, too).

Now, don't be mistaken, I'm not containerizing because it's the best solution (the best solution is called AppImage), but because flatpak basically REQUIRES its own view of the filesystem (namely the /app folder). However, we don't isolate more than absolutely necessary, because the whole point is to run the programs as natively as possible.

Usage

First of all, you need to build the project. This is done via the make command. You will need lua 5.4, curl, zlib and some sort of cc installed. The executable will be dst/slimpack. Feel free to copy it to ./local/bin/ or /usr/local/bin/

The CLI of slimpack works in a very simple way - first, you specify the generic options (for now, only --repo is available), followed by the action. Each action has its own options and then its own subaction and so on.

In syntax form, it looks like this:

[--global-opt-1 --global-opt-2 ...] <action> [--action-opt ...] <subaction> [--subaction-opt ...]

Sometimes, if an action is final, it might just take a plain argument (like how pack will just take one argument which is the ref to pack)

Querying

The first action is query. It groups all operations that are related to asking questions about a flatpak remote.

To find a ref, you can use slimpack query search <name>. This is case-insensitive, but you need to be careful with dashes and underscores. Usually, you will care about one result - app/.../x86_64/stable. The rest, for all intents and purposes, may be ignored.

To find out more info about a ref, you can do slimpack query info <ref>. This will print some information about the package, like its version, license, dependencies, etc.

Packaging

The star of the show is the packaging - this will take a flatpak package and repack it into a self-contained executable (not too unlike AppImage). To repack a package, run slimpack pack <ref> -o <output-filename>. This will eventually, after a lot of stdout spam, write an executable file to "output-filename". When run, it will just run the flatpak application without (a lot of) containerization, without any fuss.