#32 Building application Flatpaks FROM the container Flatpak
Closed 4 months ago by otaylor. Opened a year ago by otaylor.

The way we build application containers now is that we start from a clean filesystem and install the application RPM, and let it pull in any runtime dependencies it needs. We then discard everything but /app.

This requires us to have, in addition to the application packages:

  • A repository with the packages that were installed in the runtime (or close enough)
  • A list of the packages installed in the runtime

But what if we instead started from the runtime and installed on top of it? Then all we would need is the runtime itself and the application packages. The advantages would be:

  • Reduced coupling to Koji (we need to be able to look up the runtime in Koji to get the list of packages installed in it.)
  • No need to configure a repository
  • Possibly better performance when building RPMs

What would we need to make this work? We'd need to include the RPM DB in the runtime image. Somewhat by accident, we're already doing this for the newest Fedora runtimes because of https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr. We'd need to have microdnf or dnf in the runtime. And then we'd need a way to view the runtime - which has just files and metadata/ at the toplevel as a normal system image that we can install into.

The Container Way

By adding some symlinks and stub directories to the runtime image, we could make it a "hybrid" where it is both an image that Flatpak understands with /files and metadata and a container that can be normally. In an experiment, adding:

lrwxrwxrwx 0/0               0 2023-10-22 09:22 bin -> /usr/bin
lrwxrwxrwx 0/0               0 2023-10-22 09:22 etc -> /files/etc
lrwxrwxrwx 0/0               0 2023-10-22 09:22 lib -> /usr/lib
lrwxrwxrwx 0/0               0 2023-10-22 09:22 lib64 -> /usr/lib64
drwx------ 0/0               0 2023-10-22 09:22 root/
drwxr-xr-x 0/0               0 2023-10-22 09:22 run/
drwxrwxrwt 0/0               0 2023-10-22 09:22 tmp/
lrwxrwxrwx 0/0               0 2023-10-22 09:22 usr -> /files
drwxr-xr-x 0/0               0 2023-10-22 09:22 var/
drwxr-xr-x 0/0               0 2023-10-22 09:22 var/db/
lrwxrwxrwx 0/0               0 2023-10-22 09:22 var/db/zoneinfo -> /etc/localtime
lrwxrwxrwx 0/0               0 2023-10-22 09:22 var/run -> ../run
drwxr-xr-t 0/0               0 2023-10-22 09:22 var/tmp/

was sufficient to be able to successfully do run Dockerfiles like:

FROM f39/flatpak-runtime
ADD application.repo /etc/yum.repos.d
RUN microdnf install <application>

The Flatpak Way

It's probably possible to create an installation environment with flatpak build-init --writable-sdk, though there might be some problems with RPMs expecting to be installed as root.

The ostree-rs-ext way?

The way that ostree commits are stored in a OCI container with ostree-rs-ext is that the container contains an ostree repository in sysroot/ostree/repo and then contains a checkout of the filesystem (as hard links in the layer) at /. If we implemented support for this style of container in Flatpak, then the checkout could be set up to work for "FROM <runtime>" Dockerfiles, but the repo would have what Flatpak needs (or two refs - one for each layout.)

This depends on supporting such images being added to Flatpak and becoming sufficiently widely available.


The symlink approach is now implemented in the current HEAD of:

https://gitlab.com/flatpak-container/flatpak-container-tools/

Which is a renamed version of this project.

Metadata Update from @otaylor:
- Issue status updated to: Closed (was: Open)

4 months ago

Log in to comment on this ticket.

Metadata