Time flies, Flatpak 1.0 was released four months ago. Today we released the next major version, Flatpak 1.2. Lets take a look at what’s new.
New User Experience
A lot of effort since 1.0 has gone into improving the commandline user experience. This includes everything from better progress reporting to search and completion.
I’ve already written a detailed post about this aspect of the Flatpak 1.2 work, so I not going to say much more about it here.
1.2 includes new commands which make it easier to manage running Flatpaks.
Like other containers, Flatpaks are just regular processes, so traditional tools like ps and kill can be used with them. But there is often a bit more to a Flatpak sandbox than just a single process – there’s a babysitter, and D-Bus proxies, and it can be a little daunting to identify the right process to kill, in a process listing.
To make this easy and obvious, we’ve added two new commands, flatpak ps and flatpak kill. For now, flatpak ps just lists basic information, but it is the natural place to show e.g. resource consumption in the future.
This functionality is available to other Flatpak front ends as well, in the form of the FlatpakInstance API in libflatpak.
Installing software is serious business, and it is well worth keeping a record of changes over time.
Flatpak now logs changes to installations and installed apps in the systemd journal. We take advantage of the capabilities offered by the journal, and write structured logs that contain useful fields like the affected remote, the commit IDs, and so on.
A particularly nice feature of the journal is that it keeps track of the originator of changes for us, so even if Flatpaks system-helper service is modifying the system installation, we still record the user who initiated the change.
You can of course use journalctl to study these logs. We also added a flatpak history command, which may be a bit more convenient, since it offers filtering and display that is more tailored to the specfics of Flatpak.
In the ecosystem
Portals are an important part of the Flatpak approach, and we’ve made releases of the portals to go along with the new Flatpak. The 1.2 release of the portals brings a new location portal, a new portal for toolkit settings, respecting desktop lockdown settings, and better validation of input in all portals.
Flatpak itself also got some changes that will improve sandboxing in the future. One noteworthy change is that Flatpak will now bind dconf defaults and locks into the sandbox. This will become useful with the next GLib release, when GSettings will no longer be using the dconf backend, allowing us to close an all-to-common sandbox hole.
In a similar vein, Flatpak is now creating a fontconfig configuration snipplet that will be used by a future fontconfig release to map font directories to their caches.
The common theme in these changes is that the libraries in the runtime need some changes to work well in a sandboxed setting. Getting these changes in place takes time, but we’re making steady progress.
Over the fence
On the desktop side, both GNOME Settings and GNOME Software will show Flatpak permissions in more detail in their upcoming releases.
Now that Flatpak 1.2 is out, we are getting ready to unveil a much-improved Flathub. Stay tuned!
7 thoughts on “Whats new in Flatpak 1.2”
What will GSettings use instead of dconf? Can you perhaps provide a link with more details? Thanks.
OK, IIUIC, the change is only relevant to the sandboxed applications. System applications will still use the dconf backend for gsettings. Thanks for the link.
Woah this was a (positive) tsunami-wall of great news! Also thanks for writing in a non-technical way both here and in the previous post covering the commandline design. I really enjoy your writing style! 🙂
Just a tiny issue here, when I’m running the command ‘flatpak history’ on Ubuntu 18.04 LTS (flatpak 1.2.0) it throws the error:
“error: history not available without libsystemd”
Is that a dependency that should have been installed with Flatpak or am I doing something wrong here?
The error indicates that flatpak was built without the libsystemd dependency. That would be good to fix.
I can now do “flatpak install meld”, which is great. So why can’t I do “flatpak run meld” (and receive an error/question only where there is more than one matching app)? This now seems weirdly inconsistent, search and install is easy, but running is still difficult. Are there plans to improve the “run” command line as well?
We already install a shell wrapper that you can alias to ‘meld’, which is arguably better than ‘flatpak run meld’.
So, its not a priority, but if a patch appears…
Comments are closed.