Flatpak and GNOME Software

I wanted to write a little about how Flatpak apps are treated differently to packages in GNOME Software. We’ve now got two plugins in master, one called flatpak-user and another called flatpak-system. They both share 99% of the same code, only differing in how they are initialised. As you might expect, -user does per-user installation and updating, and the latter does it per-system for all users. Per-user applications that are specific to just a single user account are an amazingly useful concept, as most developers found using tools like jhbuild. We default to installing software at the moment for all users, but there is actually a org.gnome.software.install-bundles-system-wide dconf key that can be used to reverse this on specific systems.

We go to great lengths to interoperate with the flatpak command line tool, so if you install the nightly GTK3 build of GIMP per-user you can install the normal version system-wide and they both show in the installed and updates panel without conflicting. We’ve also got file notifications set up so GNOME Software shows the correct application state straight away if you add a remote or install a flatpak app on the command line. At the moment we show both packages and flatpaks in the search results, but when we suggest apps on the overview page we automatically prefer the flatpak version if both are available. In Ubuntu, snappy results are sorted above package results unconditionally, but I don’t know if this is a good thing to do for flatpaks upstream, comments welcome. I’m sure whatever defaults I choose will mortally offend someone.

Screenshot from 2016-07-05 14-45-35

GNOME Software also supports single-file flatpak bundles like gimp.flatpak – just double click and you’re good to install. These files are somewhat like a package in that all the required files are included and you can install without internet access. These bundles can also install a remote (ie a reference to a flatpak repository) too, which allows them to be kept up to date. Such per-application remotes are only used for the specific application and not the others potentially in the same tree (for the curious, this is called a “noenumerate” remote). We also support the more rarely seen dummy.flatpakrepo files too; these allow a user to install a remote which could contain a number of applications and makes it very easy to set up an add-on remote that allows you browse a different set of apps than shipped, for instance the Endless-specific apps. Each of these files contains all the metadata we need in AppStream format, with translations, icons and all the things you expect from a modern software center. It’s a shame snappy decided not to use AppStream and AppData for application metadata, as this kind of extra data really makes the UI really beautiful.

Screenshot from 2016-07-05 14-54-18

With the latest version of flatpak we also do a much better job of installing the additional extensions the application needs, for instance locales or debug data. Sharing the same code between the upstream command line tool and gnome-software means we always agree on what needs installing and updating. Just like the CLI, gnome-software can update flatpaks safely live (even when the application is running), although we do a little bit extra compared to the CLI and download the data we need to do the update when the session is idle and on suitable unmetered network access. This means you can typically just click the ‘Update’ button in the updates panel for a near-instant live-update. This is what people have wanted for years, and I’ve told each and every bug-report that live updates using packages only works 99.99% of the time, exploding in a huge fireball 0.01% of the time. Once all desktop apps are packaged as flatpaks we will only need to reboot for atomic offline updates for core platform updates like a new glibc or the kernel. That future is very nearly now.

Screenshot from 2016-07-05 14-54-59

Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

12 thoughts on “Flatpak and GNOME Software”

  1. Very nice works. Thanks a lot.

    In the last screenshot. Why “Install” buttons instead of “Update”?

      1. Make it update. “Install” would be confusing for users. What you see is app at the left which you want to update, not install.

  2. I would love to see that “very nearly future” but to result in a reasonable user experience for all updates two other things have to happen, too.
    1) The distribution you’re using needs to install Flatpak apps by default and not “core system” versions of let’s say Libre Office for example.
    2) The systemd atomic updates meets to change that it switches to single user mode without reboot for the update. At the moment the gnome “install updates and shutdown” results in a reboot into the update with hangs on manny systems because of boot order, bios password or Luks encryption.

    Both isn’t likely to happen any time soon I think.

  3. May is a good idea if you can show some details about packaging of the software, while there are flatpak and snaps, there are some others out there, then if are added as plugin to Software, then may pointing on Third Party tag this info could be shown in a tooltip.

  4. This have the posibility to be really nice! Great job! Having flatpak well integrated in to Gnome Software will give it a great user interface.
    One thing I have noticed, when I tried Gnome Software and flatpaks in F24 is that if I have multiple versions of software available/installed, it is not obvious from the overview which is which. Like in your first screenshot with multiple polari installations. It would be nice to see a version number and possible which repository it is from.
    Also I noticed that when I open the flatpak version of, in my case, LibreOffice, there are no Version information available.

  5. Thanks a lot for your work.

    Waiting for an AUR style repository full of flatpacks to enjoy and or plenty of them inside the same AUR

  6. In your first screenshot, I’m really confused into what is a flatpak and what is a rpm.. Until distros switch to using flatpaks “natively”, maybe you should hide RPMs if you have a newer matching flatpak available, or something like that.. Or maybe clearly mark “apps” (flatpak” as different from system apps” (rpms), or maybe “Fedora built-in” or something like that.

Comments are closed.