Basic Idea
xdg-app has two types of artifacts, runtimes, and applications. When a xdg-app application is executed, a container is created where the runtime is mounted at /usr and the application and bundled libraries are mounted at /app. The runtime contains a standard set of libraries and other files that are shared across multiple applications.
We want to create applications and runtimes out of RPMS. A runtime can be created out of normal Fedora rpms, but for an application, we need to have both the application RPM and any library RPMs that are bundled in the application RPM relocated to /app rather than /usr. So we need to be able to build new versions of Fedora rpms that are relocated to /app. These can be treated as additional architectures - perhaps named “x86_64+app”. Only a small subset of Fedora packages will need to be rebuilt for these architectures: only the Fedora packages which are turned into xdg-apps and the libraries they require that aren’t part of the runtime.
Packager Workflow
- A packager identifies a package as a candidate for creating a xdg-app for.
- They mark the application to be built as an app (koji xdgapp-add f25 inkscape.) This internally adds the +app architectures to extra_arches for that package in that tag.
- They bump and rebuild the package
- They try and build the xdg-app (koji xdgapp-build inkscape)
- If that fails because of missing library dependencies, they ‘xdgapp-add’ and rebuild these dependences, and repeat the xdg-app build.
Phase 1 - manual enablement
- Support in koji for x86_64+app architectures. These architectures have have different RPM configurations so that things are installed in /app rather than user. They are also “multiarch”, so that packages from the base arch are pulled in when building.
- A way to add these extra architectures to a particular package in a particular tag - probably done as a koji plugin adding ‘xdgapp-mark.’ (Currently it only seems possible to set extra architectures when adding a package to a tag, and only for an admin.)
- A koji plugin to add ‘koji xdgapp-build [--runtime] NVR’ which takes an existing package that has been built for the +app architectures, and converts the RPM and it’s dependencies into a xdg-app bundle (either existing ostree delta or future OCI image).
Enhancement: autoimport into a ostree repository
- When new app/runtime bundles are built, automatically import them into a ostree repository. (Or testing/release repositories based upon how the source rpms are tagged) Conceivably this could be handled by a new separate service that listens on the message bus, rather than trying to extend koji.
Enhancement: autorebuild of xdg-app bundles
- When packages are rebuilt that are part of xdg-app apps and runtimes, automatically trigger rebuilds of the runtimes. This would require tracking the packages in each app or runtime. This might be handled by the same daemon as above.
Enhancement: generalize this to server containers
- The basic idea of taking RPMs and converting the rpm and dependencies into a container via rpm-ostree is applicable to containers as well. The autorebuild and autoimport into ostree steps would be useful for this as well (but also probably auto-push to a docker registry.) One challenge here is that while an RPM of a desktop application is “self-describing” - it contains the .desktop and appstream files that specify what the application is and how to run it, turning an RPM of, say, etcd into a useful container probably requires extra metadata and configuration files.
Enhancement: merge in +app architectures to an existing build
- It might be nice to avoid the bump+rebuild, as envisioned by the mergeScratch RPC call that was added https://lists.fedoraproject.org/pipermail/buildsys/2015-April/004628.html
Enhancement: auto-rebuilding dependencies
- Tooling so that when someone wants to build an application that has not previously been built for +app, all the build dependencies are queued for adding to the +app architectures and rebuilt in the right order.