Flatpaks in Fedora – now live


I’m pleased to announce that we now have full initial support for Flatpak creation in Fedora infrastructure: Flatpaks can be built as containers, pushed to testing and stable via Bodhi, and installed by users from registry.fedoraproject.org through the command line, GNOME Software, or KDE Discover.

The goal of this work has been to enable creating Flatpaks from Fedora packages on Fedora infrastructure – this will expand the set of Flatpaks that are available to all Flatpak users, provide a runtime that gets updates as bugs and security fixes appear in Fedora, and provide Fedora users, especially on Fedora Silverblue, with an out-of-the-box set of Flatpak applications enabled by default.

At a technical level, a very brief summary of the approach we’ve taken is to take Fedora RPMs, rebuild them with prefix=/app using the Fedora modularity framework, then using the same container build service we use for server-side containers, create Flatpaks as OCI images . Flatpak has been extended to know how to browse, download, and install Flatpaks packaged as OCI images from a container registry. See my my talk at DevConf.CZ last year  for a slightly longer introduction to what we are doing.

Right now, there are only a few applications in the registry, but we will work to build up the set of applications over the next few months, and hopefully by the time that Fedora 30 comes out in the spring, will have something that will be genuinely useful for Fedora users and that can be enabled by default in Fedora Workstation.

Special thanks to Clement Verna, Randy Barlow, Kevin Fenzi, and the rest of the Fedora infrastructure team for a lot of help in making the Fedora deployment happen, as well as to the OSBS team and Alex Larsson!

Using it

From the command line, either add the stable remote:

flatpak remote-add fedora oci+https://registry.fedoraproject.org

Or add the testing remote:

flatpak remote-add fedora-testing oci+https://registry.fedoraproject.org#testing

There is no point in adding both, since all Flatpaks in the stable remote are also in the testing remote. (The plan is to eventually that most users will simply use the stable remote, and there will be links in Bodhi to make it easy to install a single application from testing.)

Note that some fixes were needed to make OCI remotes work properly system-wide. These were backported to the Fedora Flatpak-1.0.6 packages, but are only in master upstream, so if you aren’t using Fedora, you should add the remote per-user instead.

Creating Flatpaks

If you are a Fedora packager and want to create a Flatpak of a graphical application you maintain, or want to help out creating Flatpaks in general, see the packager documentation. There is also a list of applications that are easy to package as Flatpaks.

Future work

One thing that should make things easier for packagers is the flatpak common module – by depending on this module, different Flatpaks can share the same binary builds of common libraries. This is particularly important for libraries that take a long time to build, or when an application needs to bundle a large set of libraries (think KDE or TeX). The current flatpak-common is a prototype, and there needs to be some thought given to the policies and tools for updating it.

Automatic rebuilds of Flatpaks are essential: when a fix is added to a library that an application bundles, the module and Flatpak should automatically be rebuilt without the maintainer of the Flatpak having to know that there was something to do – and then the maintainer should be notified, either with a link to a build failure, or, more hopefully, with a link to a Bodhi update that was automatically filed. Adding Flatpak support to Freshmaker and deploying it for Fedora is probably the right course here – though not a small task.

Another thing that I hope to address in the near term is signatures. Right now the authenticity is checked by downloading a master index from https://registry.fedoraproject.org that contains hashes for the latest versions of applications. But having signatures on the images would add further protection against tampering, and depending on how they were implemented, could allow things like third party signatures added by an organization’s IT department. There’s quite a bit of complexity here, because there are multiple competing signature frameworks to coordinate: not just Flatpaks native signatures, but multiple different ways of signing container images.

A more long-term goal is to create a way to download updates to Flatpak container images as deltas, so that every update is not a full download. Reusing OCI images for Fedora Flatpaks has strong advantages for creating a common ecosystem between server applications and desktop applications, but on the server side, reducing bandwidth usage for server updates was usually not an important consideration, so the distribution strategy is simply to download everything from scratch. Hopefully work here could be shared between Flatpaks and the server usage of OCI images.


  1. Luya Tshimbalanga
    Posted December 4, 2018 at 9:59 pm | Permalink

    Wearing Design Suite lab maintainer’s hat,Does flatpak handle addons?

    • Owen
      Posted December 5, 2018 at 1:07 am | Permalink

      Flatpak has an “extension” mechanism that could potentially be used for this, though we don’t yet have any support for it in the Fedora build system. Do you have an example that you are thinking of in particular? Are there add-ons packaged in Fedora?

      • Luya Tshimbalanga
        Posted December 5, 2018 at 1:35 am | Permalink

        One of examples are LuxRender-blender(soon to be replaced by blender-luxcorerender) and Yafaray for Blender.

        I also maintain several Gimp add-ons like dds, wavelet-decompose (though I may possibly retire it now that Gimp 2.10.x has built-in version), and layer-via-copy-cut among them.

        I am interested to build a Design Suite lab version of Silverblue as a showcase example for the Design team.

      • Owen
        Posted December 5, 2018 at 10:41 am | Permalink

        If you have Flathub enabled, you can look at how hexchat appears in GNOME Software to see how application add-ons via extensions appear to the user. (https://blog.tingping.se/2018/03/18/flatpaking-plugins.html explains the technical details.) There’s no conceptual reason we couldn’t enable that for Fedora builds, or for GIMP/Blender (one restriction is that extensions can’t install things system-wide – just in a specified extension directory- so depending on how LuxRender works there might need to be some fiddling around and setting LD_LIBRARY_PATH)

      • Luya Tshimbalanga
        Posted December 6, 2018 at 2:27 am | Permalink

        Thank you for the link Owen. If I understand,flatpak spec is written in json. I will take a look.

  2. Zlopez
    Posted December 5, 2018 at 8:36 am | Permalink

    I tried to add fedora flatpak repo on Silverblue, but I can’t list the packages.
    I added the repo using
    `flatpak remote-add fedora oci+https://registry.fedoraproject.org`

    But when I try `flatpak remote-ls fedora`, I’m getting `error: lgetxattr: Permission denied`

    • Owen
      Posted December 5, 2018 at 10:19 am | Permalink

      This looks like the system-wide install problems we fixed recently. You’ll need flatpak-1.0.6-3.fc29 – which is in the latest f29 Silverblue. If you’ve already added the remote with an older Flatpak., it may be necessary to remove and add the remote to get everything to fully work.

  3. asciiwolf
    Posted December 5, 2018 at 9:16 am | Permalink

    Cool! Just one small thing about the EoG Flatpak: “file access: host” – is the full host file system access really necessary?

%d bloggers like this: