Flathub is a third party repository of applications that are packaged in the Flatpak format. Many Flathub apps are also in the main Fedora repositories, but in some cases it ships newer and in-development versions of these apps. Additionally, Flathub also contains some applications that aren’t yet in Fedora.
Fedora can be easily configured to show applications in Flathub in the Software application in Fedora Workstation. This short tutorial will walk you through the steps of getting Flathub apps to show up in Software.
Get and install the Flathub repo
Go to the Flathub website, and on the main page, there is a link to their repository file. Download, and open with Software Install:
Software appears, and to install the repo, simply click Install.
Note: Flathub is a third party repository of software that is not in the Fedora distribution. As such the Flathub repo may have different licensing and other requirements that differ from Fedora.
Search for a Flathub Application
Now, when you search in GNOME Software, you should start to see applications that are available in Flathub. For example, one app that is not in the Fedora, but is in Flathub is Peek. Do a search for Peek, and see if it appears. Note the Source: dl.flathub.org at the bottom of the entry to signify that this software is from Flathub.
Apps from Flathub may take a while before showing up in Software. You can speed up this process by manually stopping gnome-software on your system with the following command in the terminal:
gnome-software --quit
Then open Software again.
Browsing the Flathub Apps
The Software interface does not yet provide a simple way to just browse the Flathub apps. Luckily, the Flathub website has a nice view of all the applications available.
Simply search the apps there, find the one you want, then search for it and install in Software on your Workstation.
Dimitri
Hi,
I look forward to a general wider flatpak adoption in Linux and I use as many flatpak applications as I can; I hope that soon all graphical applications can be used as flatpaks.
I think that it is a major step to get non-tech users to use Linux on their machines (same applications and installation steps for all major distributions, latest versions, no dependencies trouble, etc…).
That said, I have a couple suggestions (as a common user) to anybody capable in making improvements:
1. the Browse Apps screen shown above should display also the application versions, and ideally group them in some way and allow filtering; right now it looks like a big grid list where you don’t know exactly what you are downloading
2. in KDE Discover (I use KDE) the “version:” displayed for flatpak applications (ex. Libreoffice) just says “stable”; useless
3. still in KDE Discover it would be nice to have a “application type” filter where you can select to display only flatpak packaged applications
Finally a question: can flathub also host commercial software or should each commercial software house have their own flathub repository? I guess that they would need to have their own repository tied to a webshop?
I don’t have a specific software in mind, just curious. While everybody obviously loves free software (in both meanings), I think that it’s important for its success that flatpak also appeals to commercial software, such as many mainstream games. Perhaps commercial software could have its own slot in the grid on the flathub page that when clicked redirects to the software house webshop. I guess a software license filter would then also be desirable on the flathub page.
To be honest, as a recent Linux full time user, the flatpak technology is one of the most exciting news in the Linux world as I always disliked the packaging diversity of the Linux world (also dependencies, and not having the latest version of an application on release day). It was one of the drivers for me to try Linux again.
Cheers
GroovieMan
Bah, that’s weired. You want that install desaster we hate in Windows!
If you want your hard-disk filled up with redundant copies of shared
objects go with it.
Besides, you never seen the power of bugzilla’s error handling.
In case of a crash, a detector collects the core and analyses it
against the installed packages. It optionally will send it to a bugzilla
error an everybody is capable to reproduce your problem.
Do you really want to get rid of this nice feature ?
Dimitri
Seen how cheap disk storage is nowadays, it’s no issue for me to have some disk space wasted for the convenience of the advantages it brings. And I personally I don’t hate the Windows install “disaster”, I actually think it works quite well.
GroovieMan
Nej,
the Windows install disaster cause multiple installation of unmanaged (forgotten) DLL’s on your disk. This means, that your isolated installation of a specific application are running on libraries, that are mostly never updated. So you have to live with security and functional problems within you application.
You like that ?
Spell it loudly: shared libraries
On the other side fully managed application system with one repository and a central managed application/library system (like Fedora now) any correction and improvement is also shared across other applications. That’s open source as its best. So if you want quality, you should think again.
jwmullally
Flatpak (through ostree) uses hardlinks to deduplicate shared object files when apps depend on the same underlying runtime. But yes there will probably be some duplication for bundled libraries, its unavoidable if they are different versions (or even same version and different buildroots).
For error reporting it makes sense for the error to be reported against the Flatpak app first, from there it can be triaged to the right component, as who knows where the real issue is.
GroovieMan
No, error reporting should go against the stable rpm/dnf managed system. If you found a bug in a referred shared lib, the knowledge of sharing your knowledge is doing this on a platform, that can be restored quickly and deterministic by others.
This is the way we managed it on bugzilla. I remember lot of discussions, where we were able to track back the behaviour of components (Networkmanager, VMware) using version, that we were able to change quckly to check the behaviour of other version.
The magic here is called systemmanagement. I am practicing this for years (started with Svr4 Unix) and i saw large networks 20.000 Unix server, that has been evolved (developed, tested, integration tested, fixed) like this. It was and i hope it still will be a pleasure to see this going on in future.
jwmullally
(I dont know how Fedora actually plans to handle Flatpak error reporting)
Yeah, RPM/DEB is awesome.
It would be nice to file reports on the App,Component combo. If the app containers were built from RPMs it would make that easy. If the App units were CI/CD built from Fedora, then when the shared component is fixed, the App bundles could be automatically rebuilt and published.
This is why I like alot of the ideas behind Modularity, it might lead to something like that, and I think its one of the best eventual outcomes for this new “rootfs image” era.
But for now, if the average user just wants to run an app and get on with their lives, nothing beats flatpak. Its basically Docker and Android/iOS apps for Linux.
I share your concerns above about Docker images, i.e. containing outdated and insecure libraries and built from God-knows-what, thats why building them out of standard RPM/DEB would be great.
jwmullally
Really this whole problem boils down to applications wanting more control over their dependencies, and having more self-contained and reproducible environments. This makes it possible for them to be built, tested and deployed as solid “units”.
Its also getting harder to coordinate all the versions of 20,000+ packages in big monolithic Linux distros, and the problem gets bigger every day with the explosion of new software. The only way to keep that going would be to convene a Grand Council to make all software LTS 🙂
GroovieMan
I would appreciate it to see some third party applications like VMware Horizon or other products, that are barely supported by their vendors in order to allow to install and use them in a cage, keeping my rpm-managed installation clean an proper.
But there is no reason to install application like audacity or other with flathub, that are already supported by your distribution or by RPM-fusion.
Dimitri
There is no reason…unless you want to have two different versions on the same machine, or be able to install the latest version the day after it releases (well, without compiling it), or care for the sandboxing security.
GroovieMan
Fedora is quite modern and you want that version, that is running reliable on your system. So the very best source is fedora-repo, RPM-Fusion. Sometimes, application-pages also provides rpm for your system.
And if you think about security, most of the application packages provide a selinux-config.
The extra effort for a package distribution is simple, you do it only one time as a make/maven target. The gain for the application (testing, distribution, up-to-date) is immense, because the app-developper can rely on the development of others, who take care on their libraries.
Packaging is discipline, but if everybody take care, it is a win for everybody, especially the user/customer.
Einer
One very important question, in my opinion……..
“Who is doing the QA on the flatpaks as it relates to:
1) Security ( Malware/Exploits)
2) Quality of code (Bugs, pure trash or actually usable)
Mehdi
Had never heard of this. Thanks for sharing.
Creep
Is anyone skilled enough to bring flathub webex app with sharing desktop ?
Grixin
As someone who has never used a snap file or flatpak before. This is awesome! Really helps stretch the “limits” of a distro. Some distros I’ve loved all aspects except availability of apps for me. This helps bridge that gap considerably. Thank you for sharing this 🙂
GroovieMan
It is the advantage of good rpm-package management, that you can update your entire system, while you sleeping. There is no limit in a distribution, that provides for a reliable update cycle.