Flatpaks are handy for avoiding dependency hell, but they do have downsides. In my case, I am running KDE but have a few gnome-based apps installed via Flatpak. So basically I need to have 3+ versions of the nvidia driver updated every few days at 300MB+ a pop. Always with the tradeoffs. Nothing is purely the obvious way to go.
Well, that is where your fancy gigabit internet and high capacity storage kicks in.
3 Likes
When you say “GNOME-based apps” are you referring to applications that are actually relying on the GNOME framework (if there is even such a thing, I’m a KDE guy and they definitely do), or are you talking about GTK?
Because GTK is likely installed on your system anyway and if it isn’t, it’s certainly smaller then even a single nvidia driver install and you could just use native packages (if there is one obviously).
But regardless, not sure why you’d need to “have 3+ versions of the nvidia driver updated” because the nvidia runtime in the Flatpak needs to match the Host driver and the runtime is only installed once. The runtime is a platform extension to the Flatpak runtime so it is available to every Flatpak, it isn’t installed per Flatpak.
That being said, yes Flatpaks as well as everything else have their pros and cons. Personally I like using native packages as much as possible. I see Flatpaks more as a place for proprietary software that can’t be rebuilt one any given library update like native packages are.
2 Likes
Nvidia runtime one is more of an issue of Flatpak is a multiple fold:
- Flatpak always automatically installs a matching runtime without uninstalling an older one unless EOL (#2917), and Nvidia runtime doesn’t really get EOL since it always needs to match the host runtime
- Each version of Nvidia runtime is provided as a separate Flatpak ref, so it could match the host. However,
flatpak uninstall --unuseddoesn’t work due to dependency resolution (#2718) - All versions of Nvidia runtimes are built from a single repository, which means every push results in a new ref of all Nvidia driver versions. You can check this by
flatpak remote-info --log flathub runtime/org.freedesktop.Platform.GL.nvidia-390-59(or some random Nvidia runtime)
This means that often times when you install a new Flatpak, or run flatpak upgrade and there were some pushes to the Nvidia runtime repository, you will see an update to all versions of Nvidia runtime that were still installed on the system.
Thankfully, downloads are just a small delta, and it only took a few minutes every once in a while to clean them up, so it didn’t bother me as much.
I try to use Flatpak as much as possible (at least where it makes sense). Partly because I like having application settings comparted into ~/.var/app, and I like having a consistent experience across distros.
3 Likes
Thanks for the comments.
@mihawk90 it seems that GIMP, DejaDup, and Flatseal (used to manage flatpak sandbox file permissions), two with gnome 45 and one with gnome 44. I suppose this is just the kind of dependency clash that flatpak is there to prevent. It’s really only noticeable since those files are so large.
dave@fedora:~$ flatpak list --app --columns=application,runtime
Application ID Runtime
com.discordapp.Discord org.freedesktop.Platform/x86_64/23.08
com.github.tchx84.Flatseal org.gnome.Platform/x86_64/45
com.jetbrains.PyCharm-Professional org.freedesktop.Sdk/x86_64/23.08
com.obsproject.Studio org.kde.Platform/x86_64/6.5
com.spotify.Client org.freedesktop.Platform/x86_64/23.08
com.valvesoftware.Steam org.freedesktop.Platform/x86_64/23.08
com.vscodium.codium org.freedesktop.Sdk/x86_64/23.08
org.blender.Blender org.freedesktop.Platform/x86_64/23.08
org.chromium.Chromium org.freedesktop.Platform/x86_64/22.08
org.gimp.GIMP org.gnome.Platform/x86_64/44
org.gnome.DejaDup org.gnome.Platform/x86_64/45
org.kde.krita org.freedesktop.Platform/x86_64/22.08
org.octave.Octave org.kde.Sdk/x86_64/5.15-22.08
@sim Thanks for pointing out that flatpak uninstall --unused doesn’t work to remove nvidia runtimes. It said “uninstall complete” for org.freedesktop.Platform.GL.nvidia-535-129-03 , but it lives on. And sometimes there is a delta download, but sometimes the whole thing updates.
Anyway, I was just intending to point out to that to avoid dependency clashes, it requires an investment in download bandwidth and storage space.
They are GTK applications, not GNOME applications. They don’t depend on GNOME.
The reason it depends on the GNOME platform is simply because GTK is provided as part of the GNOME platform in Flatpaks. There’s only 4 Platforms to choose from, but that doesn’t mean that an application is going to use everything the chosen platform provides.
Counterexample: OBS Studio is based on the KDE platform. Why? Because OBS is a Qt application and Qt is provided in the KDE platform. OBS is not a KDE application either though, it runs entirely without KDE-specific dependencies (i.e. the KDE Framework), just the same as your three examples don’t rely on GNOME-specific dependencies, but they rely on GTK.
The platforms are just a handy way for applications to get a whole bunch of dependencies at once. Theoretically every application could be built on the freedesktop platform, but that would require building every single dependency during build time and depending on the application that would a) require hours of compile time and b) would duplicate even more dependencies across Flatpaks because now they would be bundled inside an application Flatpak instead of the the Platform.
Example: We established all 3 applications depend on GTK. If all 3 were built on the freedesktop platform, it would require for all 3 to build the entire GTK dependency tree, and every application would then bundle their build of GTK (which may or may not be the exact same version), using up 3 times the disk space that it currently does.
So coming back to my previous post: all 3 could in theory be built and used on any system without having GNOME be used or even installed by just installing GTK as a dependency.
2 Likes
Thanks for the clarification!
Indeed… But wait… Isn’t that what .deb / .rpm already do? 
To be fair though, with Yocto Linux almost trivializing the art of custom Linux distros, FlatPaks might soon turn out to be redundant, all you need to do is run a bare metal hypervisor with passthrough of certain key components, and voila, most apps run on a 100 MB binary that runs inside a VM and has all dependencies baked in.
It does feel a bit excessive to have 100 MB to run a 25kb Hello World program, but eh. Win some, lose some I guess 
That was the point?
1 Like
If you have slow Internet you can try to follow this guide. I just implemented this the other day and it works great to speed up Flatpak updates on my super slow home internet, especially with multiple machines.
2 Likes
Of course with nvidia stuff … not ideal, but quite the best to have a working system is the true portable app that are simply put in place, in anyplace : Appimage. 1 file, full working.
Also, ask why the need to update something every 4-5hrs ? Of course bug are submit to dev and then a new version is push to test… but all in all for a working system, appimage is quite the key.