flatpak list --columns name,branch,origin,size,runtime
Name Branch Origin Installed size Runtime
Slack stable flathub 2,8 MB org.freedesktop.Platform/x86_64/18.08
Freedesktop Platform 18.08 flathub 822,5 MB
default 19.08beta gnome-nightly 104,7 MB
Adwaita icon theme 1.0 gnome 27,5 MB
Intel VAAPI Driver 1.6 gnome 8,7 MB
Intel 18.08 flathub 8,2 MB
Intel 19.08beta gnome-nightly 8,2 MB
FFmpeg extension 1.6 gnome 7,7 MB
ffmpeg-html5 19.08beta gnome-nightly 8,1 MB
html5-codecs 18.08 flathub 8,8 MB
Evince stable flathub 28,2 MB org.gnome.Platform/x86_64/3.32
Giochi master org.gnome.Games-origin 34,1 MB
GNOME Application Platform version 3.26 3.26 gnome 1,3 GB
GNOME Application Platform version 3.28 3.28 flathub 1,3 GB
GNOME Application Platform version 3.30 3.30 flathub 992,2 MB
GNOME Application Platform version 3.32 3.32 flathub 1,0 GB
GNOME Application Platform version master master gnome-nightly 928,8 MB
Why I have 5 installation of GNOME Application Platform version? Using 5 GB (on a SSD disk) and only one is used? Isn’t flatpak removing not used dependecies?
Hi @wiso! Welcome to the community! Please do take a few minutes to go over the introductory posts in #start-here when you have the time. They contain lots of useful information.
First of all, you can try
flatpak remove --unused
If some runtime versions are not needed anymore – flatpak will delete them (it doesn’t do this automatically).
As for why – well, basically there are two reasons:
Application updates – some applications may have been using older version of the runtime (i.e. 3.28), then after some updates they rebased to a newer version (i.e. 3.30). Flatpak won’t automatically remove runtimes no one needs anymore. Solution/workaround is above.
Various applications you’ll find on Flathub (and elsewhere) require different versions of the platform. For all the applications to switch to one newest platform version packagers/maintainers for each of the applications should repackage/rebase their respective flatpaks to this one version.
And it seems that Flathab packagers/maintiners are not very interested in doing so. I’ve heard quite a lot of criticism lately addressed to Flathub policies, packagers and maintainers. This exact “runtime hell” was provided as one clear indication of a poor state of things. Also critic stated that flatpak’s specs (on the Flathub) are often of a very poor quality, and at least some maintainers are unwilling to accept patches or even to communicate.
There’s some talk about Fedora’s own flatpak repo, but, as far as I understand, for now developers aren’t sure of how to implement it. Maintaining two separate package versions (traditional rpm and flatpak) is too much of duplication of efforts for quite a few Fedora maintainers, and automatically converting existing packages to flatpaks has some drawbacks too.
That’s the summary of what I’ve heard / read on the subject.
I myself use some flatpaks from Flathub – but sparingly and with understanding that right now there’s no way around multiple runtimes problem.
Thank you, your command is what I needed.
I hope that the ones who proclaim to be “The Future Of Apps On Linux” will fix 1. otherwise “The Future Of Apps On Linux” will be a mess
It would appear you also have more than one remote setup (ie gnome-nightly, flathub, etc) possibly there is one or more flatpak apps you installed that required the extras (runtime versions can be critical for some apps).
Moreover, from what I see, each flatpak requires one or more of runtimes with one precise version. And different flatpaks require different ones.
@wiso, my own thoughts are that the idea is good. Though I would never try to replace rpms with flatpaks, that’s a bad idea imho, we need both, they both have their pluses and minuses, and correspond to different needs.
For example, flatpaks are bad when storage space and bandwidth costs are at premium.
I can’t wouch for technology, don’t have qualification to do so – I hope the developers are good).
This trouble we have now – it’s the distribution problem, not a technology one. We heed a proper repository with good trusted maintainers and strict guidelines. Maybe also with automatic rebuild to newer runtimes, so that maintainers wouldn’t have to do it manually. Basically what we have with proper Linux distributions – Fedora, Debian, etc. – people do know already how to do this properly. Also maybe there was somewhat similar problems with Linux repos a long time ago (if they ever were, then more than 10-12 years ago). So for Flathub it’s a problem of immaturity, I’d say.
And I think that we’ll see one of the two things: either in time Flathub will mature, good maintainers overtake flatpaks from the bad ones, etc. Or other good repos will appear, and noone will use the Flathub ) Sort of evolutionary natural selection. )
Each Flatpak app will be built with one runtime targeted. The Gnome runtimes are based on the Freedesktop ones, as are Fedora’s. I use Fedora Silverblue as my “daily driver” and develop from it, sometimes with a flatpak IDE, but also in a PET container, both have their roles for me. This is part of the reasoning behind why flatpaks default to system instead of user, so you don’t get too many flatpaks pulling in the same runtime for their own use, instead the first step is to check if the dependency runtime is already installed. If you install apps in flatpak as user, and there are more than one user on the system, you can potentially have the same runtime installed by each user, effectively increasing storage use (of the considered runtime) by a multiplication factor of the number of users. This also doesn’t account for the stack of dependencies the app itself will install on the system, or in the case of a --user option install, it will go into the users home directory under $HOME/.local/share.
[EDIT]: RPM’s aren’t going anywhere as far as I can see, in the near or distant future. They are one step in the process to making a flatpak in Fedora, RPM>FEDPKG>FLATPAK. RPM’s are still the method of upstream application deployment, and likely will be for some time. The concept of flatpaks is basically a container, providing a stable known state for the app to run in and sandboxing it from system critical areas.