Fedora is a distribution that does not shy away from emerging technology (after all, one of its founding principles is First). So it comes as no surprise that Fedora is on the leading edge of a revolutionary new software package system. This is not the first time Flatpak has been mentioned on the Magazine, but since Flatpak is so new, a lot has changed since last time.
What is Flatpak?
Flatpak can roughly be described as a modern replacement for RPMs, but its impact is far more significant than simply offering a new packaging format. Before we go into what Flatpak offers, first consider the current software delivery flow present in Fedora today.
- Upstream authors work away at a new version, ultimately producing an archive containing source code (frobnicate-0.4.2.tar.gz)
- Distribution packagers receive a notice that their upstream team has released a new version
- Distribution packagers download the source archive, and build the new version for all supported distributions, producing a binary RPM (frobnicate-0.4.2-1.fc26.x86_64.rpm) for each distribution
- Distribution packagers submit the binary RPMs to the appropriate update system, pushing the RPMs through the workflow so that…
- Finally a user can download the new version of frobnicate (dnf upgrade frobnicate)
This process from start to finish can take anywhere from a few days to months or more. Flatpak provides tooling to both the upstream developer and the end user that dramatically shortens the time between an upstream release and a binary arriving in a user’s dnf update. Now let’s revisit frobnicate, but with Flatpak in place both with the upstream developer and the end user.
- Upstream authors work away at a new version, ultimately producing an archive containing source code (frobnicate-0.4.2.tar.gz)
- Upstream authors build a Flatpak repository using flatpak-builder
- Upstream authors push the new repository to a URL already known to their users and/or advertised on the project website
- End user receives the new version of frobnicate during flatpak update
Flatpak directly connects the upstream author with the end user; there are no distribution intermediaries involved. Flatpak uses OSTree to build a file-system containing all the dependent libraries and files necessary to run the desired program. This means a single Flatpak repository can run on all Linux distributions capable of running the flatpak program. In addition, because OSTree repositories can be branched, different versions of the same program can be installed at the same time (Imagine having both a stable, released version installed as well as a nightly developer version!). Finally, Flatpak runs each program inside a sandbox environment, requesting permission from the user before accessing hardware devices or files.
Set up repositories
Anyone can host a Flatpak repository, but it requires a server and some tooling to maintain. As a result, a few software teams have coalesced around a couple different major repositories.
GNOME
The GNOME development team hosts a repository containing nightly builds of all the core GNOME apps, as well as many additional applications. To add the gnome-nightly repository, open Terminal and run:
flatpak remote-add --if-not-exists gnome-nightly https://sdk.gnome.org/gnome-nightly.flatpakrepo flatpak remote-add --if-not-exists gnome-apps-nightly https://sdk.gnome.org/gnome-apps-nightly.flatpakrepo
Flathub
A team of Flatpak developers have started a project known as Flathub. Flathub aims to provide a centralized repository for making Flatpak applications available to users. Flathub covers more than the GNOME application suite, and is regularly adding new applications. To add the Flathub repository, open Terminal and run:
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
Applications
GNOME Software already supports Flatpak repositories, so applications can be installed either with GNOME Software or with the flatpak command. Launch Software from the Overview, click the Search button and search for the desired application. If it is available in the traditional Fedora repositories as an RPM, there are two results.
- The entry labeled Source: fedoraproject.org is the RPM.
- The entry labeled Source: sdk.gnome.org is the Flatpak.
Select the Flatpak entry and click Install.
Once installed, Polari can be launched from the Overview like any other application; the GNOME shell already supports Flatpak applications.
The flatpak command also lists and installs apps and runtimes. To list all apps available in a specific repository, run the remote-ls command:
flatpak remote-ls flathub --app
Install an app with the install command:
flatpak install flathub com.valvesoftware.Steam
Once installed, the run command will run the application:
flatpak run com.valvesoftware.Steam
Build your own
Can’t find your favorite applications on Flathub or elsewhere as a Flatpak? Building your own is actually fairly straightfoward. If you are comfortable compiling software “by hand”, creating a Flatpak repository will seem quite familar. Flatpak repositories can be built a couple different ways, but the simplest method is to create a JSON formatted file called a “manifest”. For example, take the GNOME Dictionary:
{
"app-id": "org.gnome.Dictionary",
"runtime": "org.gnome.Platform",
"runtime-version": "3.22",
"sdk": "org.gnome.Sdk",
"command": "gnome-dictionary",
"finish-args": [
"--socket=x11",
"--share=network"
],
"modules": [
{
"name": "gnome-dictionary",
"sources": [
{
"type": "archive",
"url": "https://download.gnome.org/sources/gnome-dictionary/3.20/gnome-dictionary-3.20.0.tar.xz",
"sha256": "efb36377d46eff9291d3b8fec37baab2355f9dc8bc7edb791b6a625574716121"
}
]
}
]
}
Save this to a file, and run flatpak-builder to create a repository.
$ flatpak-builder gnome-dictionary-app-dir org.gnome.Dictionary.json
Resources
There are a growing number of useful resources for building and using Flatpaks.
Bryce Hardy
“Flatpak directly connects the upstream author with the end user; there are no distribution intermediaries involved.”
This leads to important questions in my mind about security which I wish the article had addressed. What kind of vetting is involved to ensure that malicious software is not allowed and how do distributions protect themselves and their users?
Matthew Bunt
Someone feel free to correct me if I am wrong, but to my knowledge flatpak uses cryptographic signatures to ensure contents of a flatpak you get on your computer are the same as the authors published. Beyond that there is a certain amount of trust involved. For example you trust the Fedora packagers, who trust the upstream developers who trust the library developers who trust the kernel developers and so on. This is known as a web of trust and it is how distributed development works today with rpm based packages and it does not change with flathub except that there will be less duplication of work at the distribution packaging level.
Any security auditing does not really change from a distribution perspective. And common sense security practices still apply. For example if you don’t trust a website you are reading you likely should not trust a flatpak repository advertised on that site.
There are still some kinks to work out but, assuming flatpak really takes off, I think it will be better than simple rpm packages from a secrity standpoint. Theoretically if more distro’s are using the same flatpaks then testing coverage, bug reporting and security auditing should all improve. Also the flatpaks themselves are sandboxed by default which is another advantage in their favor.
Bryce Hardy
Thank you for this clarification. I still feel that I trust the distribution packagers more implicitly and would generally be wary of flatpaks unless I knew a lot about the upstream authors.
Roeland
Security is an issue yes. Does not go through testing for instance. No way to see if the integration works etc. Bad idea.
I do trust the repo maintainers. And no, that is not epel for instance.
Kris Knigga
“Flatpak directly connects the upstream author with the end user; there are no distribution intermediaries involved.”
How is that different than the upstream author publishing their own RPMs in their own yum/dnf repo?
Matthew Bunt
The idea of developers publishing their own rpm is similar to supplying a flatpak. However, as a developer using flatpak you know that any system that supports flatpak will be able to resolve your dependencies. That is not guaranteed with rpm, as sometimes the dependencies might not be readily available (like if they are very old or very new or just not packaged).
Maimela
hey you guys, you must make fedora 27 come with kde connect!!
Kevin Kofler
KDE Connect is already included on the Fedora KDE Spin and available in the repository for all Fedora users.
Einer
I have the same security concerns as it relates to a “Supply Chain Attack”. At least the distribution hubs have some vetting in place, you have to be a known member to put anything into the distribution.
As described, FlatPack would potentially allow an UNKNOWN/UNVETTED developer to distribute potentially damaging software directly to the consumers with no accountability.
Madalin Ignisca
How is it different than Snaps?
Groovy
For a long time we have a very stable and a reliable package infrastructure with rpm and their repository. The integration work at Fedora was great, to interweave applications into the Fedora infrastructure. An application crash or a selinux-exception could be easily automatically analyzed
and associated with a package and a bigzilla entry.
Looking back to the problem we solved, i learned, that there are a couple of dependencies between a
single application an some system components. The issues with the KDE network managers and the
base system was a good example to me, that shows how important the integration jobs was and
is.
I see real problems, when this work is beeing dropped in favour of a hilly-billy snapshot of a developers disk image. Some applications will prudently fail, cause developer A does not know the changes
that developerB did. Besides i see a real problem with the security of fedora in future.
No, F26 was my last distribution.
Thank you for your good work in the past!
davidva
If fedora changes to a similar model “Rolling release” a rpm is compatible with all Fedora version. A flatpak build shows the same problem to a rpm/deb build, differents versions in “build dependencies” imagines a flatpak was built in a ubuntu machine; then the dependencies change drastically if the flakpak will be installed in Fedora… We have a serious problem with the cicle of updates in packages and paths of all distributions linux. Here a simple example about It… https://repology.org/metapackage/glib/versions