In another page, I described my adventures converting an Ubuntu DEB package to an RPM package. This provided me with a native toolchain for my Linux workstation.

I wished though that there was a solution that would allow far more Linux users, no matter what distro they use, to have a gcc-ia16 toolchain. Just as much for my self-education, I looked at the main contenders for portable packages, which are: flatpak, snap, and appimage. In this project I'll detail my adventures building a flatpak package.

Flatpak technology

Flatpak is based on Linux namespaces which allow processes to run in a container, which is a modified environment from processes in the host environment. Think of chroot on steroids as a first image. But don't hold onto that image, because containers are far more than that; more capable and more secure.

Containers are also called sandboxes. For example one can expose only part of the host filesystem (a filesystem is a type of namespace) to the container. It took many versions of the Linux kernel to develop all the available types of namespaces, but the set is now complete. You will find containers in development and production situations (think of a server hosting multiple containers), but closer to home you will find that the Firefox and Chrome browsers use containers to enhance security. Just do a lsns(1) on your Linux system and you will see those browsers listed.

This barely scratches the surface of namespace and container technology and you can find documents for deeper study.

Flatpak runtimes

Flatpak is based on a set of standard runtimes. There are runtimes for a generic desktop environment, and for GNOME and KDE. SDKs are provided for all these runtimes to build an application. The completed application will run in an environment containing the specified runtime, plus any accompanying resources for the application itself. To make it concrete, imagine that your GIMP application when running has access to an environment containing the standard system devices and libraries, plus any resources it needs to run, e.g. additional libraries, icons, data, scripts, etc., all inside the container's filesystem.

Flatpak prerequisites

First of all the flatpak tools should be installed. Most mainstream distros have packages for this.

Next the desired runtime and SDK needs to be installed from the Internet. Runtimes are versioned and generally new ones issued each year. In the case of this project, org.freedesktop.Platform and org.freedesktop.Sdk are needed. Unfortunately there isn't anything more spartan, say only for command line applications of which the gcc toolchain is one, available so we choose the simplest one.

Building a flatpak

Flatpaks are described by a manifest, which is a YAML or JSON (your choice) file describing how the application is built from the sources. Generally the sources are fetched from the Internet as tarballs, zip files, or Git downloads.

Unfortunately documentation is where Flatpak technology is deficient. If you go to their website you can find a Hello World example which will get you started. But very quickly you will be searching for "how do I" explanations with frustration. The documentation is lacking in a roadmap that will help users go from a Hello World build to a real-world build. Also the documentation writers seem to be diagram and graphics adverse. Assuming you have the prerequisites, that is the flatpak tools and the runtime platform installed, here are the steps in outline:

1. Mkdir a build directory. This is usually called build-dir in the documents, and that name is as good as any. I put mine in /tmp because it's on a solid state disk so compilation is fast.
2. Choose an application ID. This is a reverse domain name that should be unique. For example I chose io.github.gcc_ia16.Gcc_ia16. Why the last name twice? The first is my project's name, hopefully nobody else will claim it, and the second is the application within that project. So I could create other...