I've just submitted a change proposal for creating Flatpaks out of Fedora package
content:
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
This is submitted as a F27 change proposal, but it's expected that it will be multiple
releases before everything in the final shape. My hope for Fedora 27 is that by the fall
packagers will be able to start experimenting with making Flatpaks out of their graphical
applications and there will be a small set of applications for users to install.
There is more extensive documentation about the technical plan at:
https://fedoraproject.org/wiki/Workstation/Flatpaks
Building Packages
=================
Flatpaks require rebuilding applications and bundled dependencies to be located with a
prefix of /app rather than /usr. We're using the infrastructure created for modules to
rebuild packages, and it has worked out very smoothly so far. There are prototype runtime
and application modules at:
https://src.fedoraproject.org/cgit/modules/eog.git
https://src.fedoraproject.org/cgit/modules/flatpak-runtime.git
Building Flatpaks out of Packages
=================================
After building the packages, they need to be combined into a Flatpak runtime or
application. There is a python script to do this locally in
https://pagure.io/flaptak-module-tools, but the goal is do this within the same build
pipeline as is used for containers, and I've started prototyping out changes to
atomic-reactor.
One element that is needed to built Flatpaks or containers against modules is published
composes of modules. This will be provided by the "On Demand Compose Service".
Development on this by the modularity team started recently, but seems to be going well.
Distributing Flatpaks
=====================
The goal is to distribute Flaptaks from
registry.fedoraproject.org. This requires passing
two hurdles:
* Flatpaks are OCI Images, not docker containers, and we don't have OCI Image support
in
registry.fedoraproject.org (which is an instance of
https://github.com/docker/distribution/) There is conceptual agreement to add this
upstream, and a pull request that is blocked on finalizing the OCI Image specification.
* For GNOME Software to provide a nice installation interface from the registry rather
than an OSTree repository, we need to have a) an index of all flatpaks/containers in the
registry b) appstream data for the containers in the registry. The cockpit team has
similar requirements for their container installation interface, and we'll collaborate
with them in coming up with a solution.
This work is still at the research and discussion phase.
Updates
=======
There is work currently underway to add support to Bodhi for filing updates for containers
rather than for packages should carry directly across to Flatpaks. This may be sufficient
for F27. However, eventually it seems like we need to have automation, where updates of
packages automatically cause updates of containers/flatpaks for those packages. This
workflow still needs to be planned out in detail.