Flatpak does a lot of things. Oftentimes people ask me “Why Flatpak?” and I only end up remembering a few off-hand, so I figured it’s time to sit down, reflect, and go over “Why Flatpak” in a nice forum thread once and for all.
Package once, identical version is installed on 20+ distros
Build server runs offline for predictable builds*
Encourages upstream to follow xdg standards (i.e. so your config files/cache files are in predictable places)
x-data-checker allows maintainers to update apps quickly
(On Flathub) Packages can be verified to come from upstream
Apps are sandboxed by default, and permissions are easily modifiable with Flatseal
Flatpaks run seamlessly on immutable distros like SteamOS
Installed apps can be individually rolled-back
Updates don’t require root
* Note this isn’t the same thing as reproducible builds, but still covers many of the same benefits
And for completeness, some disadvantages of Flatpak:
Worst-case scenario you’ll have two identical copies of the same library on disk (although mitigable with FS compression like BTRFS)
App library dependencies happen independently of the package manager, requiring more bandwidth
Apps requiring root priviages (like VPNs) can’t be packaged
CLI apps don’t appear on Flathub and are otherwise awkward to use
Configure the sandbox a bit more conveniently, as opposed to Firejail, or even bubblewrap directly
No need to create a new desktop entry if you need to persistently set environment variables, socket, etc. strictly for a specific app (except Electron)
And to complete with a disadvantage:
Strong dependency to XDG portals. If a portal doesn’t exist for a specific use case, then you’re out of luck, as you have to rely on static permissions, or can’t do anything about it.
Here’s a concrete disadvantage, which is a spin on the dependency to XDG portals:
Accessing a serial port works, but only if it’s connected on app launch. And if that device reboots in between (when you flash something for e.g.) it will not show up without restarting the app.
A rational straightforward manifest to define the application, rather than a cobbled-together collection of random files and circularly-linked documentation.
The aim of the well-mannered people running it is to do everything in their power to help you get your Flatpak published. Unlike other packaging systems where the aim is to keep the plebs out of their “old boys club”.
Honestly I find the documentation for the manifest one of the worst parts about Flatpak.
The documentation linked on github.com/flathub/flathub should be the differences between what Flathub wants and what Flatpaks need (in those terms, not “app submission” and “app requirements”), and then the manifest documentation itself should be a skeleton example with links to learn more about each part. Right now that requirements page is non-chronological with no example, and lists optional & uncommon features with the same emphasis as required ones. To top it off, it’s hosted on Github pages so contributors can’t submit any patches to improve it. docs.flatpak.org isn’t a solution either, since it is an absurd amount of information to go through for someone trying to package their first binary app, and doesn’t actually address many of Flathub’s own needs.
The result of this is over 50% of the app submissions include egregious mistakes, and while I commend the patience of hflguiere to go through them, handling this at the documentation level would save both the submitters and maintainers extra stress.
If it weren’t for that buildbot, I think hflguiere would be bald.
Creating our own docs that coexist with the flatpak docs is on my (personal) roadmap.
GitHub - razzeee/flatpak-docs-docusaurus is currently only a slimmed down version of the flatpak docs and an added blog. But I hope to start working on docs that are more flathub focused. I’ve also talked with barth about this, but the website relaunch has a higher prio right now.
I do have some thoughts about a new possible outline for docs, but haven’t written them down.
This will only happen if you installed an application in two separate repositories—e.g. your user’s and the system’s repository—which is something that doesn’t really happen.
Identical files in the same Flatpak installation repository are de-duplicated on disk.