Meta tracker for future work

[ryanabx]

Here's a few ideas on ways this could be extended. I probably won't work on these, as this was mostly just a fun day project, but if anyone would like to contribute here's some ideas!

• [ ] Support loading from .flatpakrefs without installing (would probably download the flatpak as normal and run it straight from the repo
• [ ] Support desktop integration (see: desktop-entry-daemon

[probonopd]

Hi, interesting project. Please define what "run ... in a portable manner" actually means. Can this be used to turn a Flatpak'd application into something that can run on systems on which Flatpak is not installed?

[ryanabx]

Hi, interesting project. Please define what "run ... in a portable manner" actually means. Can this be used to turn a Flatpak'd application into something that can run on systems on which Flatpak is not installed?

Hi, thanks for the interest!

The project does require flatpak to be installed, and the runtime is not bundled with the application in this scenario. I think the idea of a fully portable application based on flatpak would be really cool, albeit with some caveats:

From what I understand, the runtimes for flatpak applications can get very large (the ones I know of are the freedesktop sdk and the GNOME and KDE sdks). Since flatpaks often share a runtime, usually this doesn't result in space concerns

Bundling the runtimes into an image would be interesting, and I toyed with the idea for a bit, but even that would still require the flatpak application, unless we do some reverse engineering on what flatpak run does, then include it in some bootstrapping code, which is certainly possible. It'd be good to calculate the drawbacks though, the two big ones I can think of are startup times and application size.

If I had unlimited time to work on stuff like this, I'd be quite the happy programmer. Desktop integration stuff is of a lot of interest to me lately.

[probonopd]

Thanks @ryanabx.

Hence, I'd say that the minimal set of files needed from the runtime(s) to run a particular application should be bundled with the application.

For example, the entirety of Qt is quite large (think hundreds of MB), but most applications only require a tiny subset of it (think under 20 MB).

This is the approach tools like https://github.com/probonopd/go-appimage/tree/master/src/appimagetool take. Maybe it could be used to convert Flatpaks into AppDirs.

One of my interests is archiving applications, so that we can still run the same application versions we are running today a few decades down the road. I am pretty uncertain whether the old Flatpak runtimes will still be available then. Hence, I'd prefer to bundle all really needed dependencies with the applications for long-term archiving.

[ryanabx]

I'm not sure what AppDirs are, but if they act similarly to ostree repositories then a very similar approach can be managed here.

A very raw but guaranteed to work approach would be to have an exclude list (like I see in the repo you shared) that users who want to package apps can use to ignore certain files that aren't needed. Basically it'd be cool to have a manifest that's like:

FROM org.inkscape.Inkscape

* include all files

---

FROM org.freedesktop.Sdk (or whatever they call it)

* exclude:
** insert a bunch of library files that aren't necessary, glob patterns can be included for an easier time **

Then the archiving program would just download the required stuff from flathub (or another remote if specified) and put it all together in one ostree repo (or two if we want to follow the flatpak way of separating runtime from app), then zip it together.

From there, a complementary program could be made to unpack the archive and run it, either using flatpak (since they have the code to mount /app and /usr already baked in) or if one would like to not use flatpak, the bootstrapping code could be embedded in the file like how appimages work.

[ryanabx]

@probonopd I'd be interested to hear about how your appimage format works sometime, particularly how you wrote your bootstrapping code to run whatever app a user executes

[probonopd]

The principle is really simple: It's an AppDir inside a squashfs image, which is prepended by a tiny binary that loop-mounts the squashfs image (using FUSE) and then executes the payload inside the AppDir.

An AppDir is just a directory that contains everything an application needs to run (that cannot safely be assumed to be there on all target systems) plus a file (script, symlink) called AppRun that executes the main payload application.

AppImages also support --appimage-extract if you just want to unpack (like a zip) rather than mount and run the AppImage.

The rest are details. Ask me anything you're interested in.

[ryanabx]

@probonopd that's remarkably simple! I can see that being done for flatpaks without requiring flatpak to run it, but afaik the runtimes would still be necessary to an extent.

Basically flatpak has ostree repositories for runtimes and applications, ostree repos being fancy git-like repos for filesystems, they can be turned into static directories though, and then you could make an AppDir out of that, just merging the runtime and app into a single appdir, or by making an appdir with two separate folders for each.

The resulting file size might be massive though, and that's where we either cull unnecessary runtime libs or separate the runtime. I'd be fine with either approach but separating the runtime does mean that a lot of common libs are accounted for across executables. I know that might partially go against the ethos of appimages though.

I see a lot of promise in converting flatpaks to single executables, I just don't have a big-picture architecture laid out in my head. If anyone were similarly interested, I'd be down to figure something out with a group. Flatpak seems to have won over a lot of distributions and app developers, so I think it makes sense to build something off of what they have built, that accomplishes the portability goals that they won't seek out.

[probonopd]

Yes: one would need to extract the OStree for the application and for the runtime(s) it needs. Then copy all of the application OStree into an AppDir (plain directory), and let a deployment tool like linuxdeploy or go-appimage's appimagetool -s deploy do the rest - deploy the parts (only) of the runtime(s) that are actually needed. The resulting AppDir could then be zipped or be put into an AppImage.

[probonopd]

Related discussion, possibly useful:

• https://github.com/flatpak/flatpak/issues/408

[ryanabx]

Related discussion, possibly useful:

• https://github.com/flatpak/flatpak/issues/408

Haha that was me at the end there! Thanks for bringing it up though 😅