Flatpaks won’t get their libs updated all at once by just updating a library. This can be very bad in cases like bugs in openssl. Instead of just updating one library and all other software benefiting from the fix, with flatpaks, you need to deal with updating everything manually and waiting for the vendor to actually create an update package.
I’m not 100% sure about this. Flatpak has some mechanisms that would allow to manage dependencies in a common fashion.
Most Flatpaks depend on the Freedesktop Platform runtime, or GNOME/KDE runtimes, which are derived from it. This contains several hundred common dependencies and librarires programs need, like gcc and python. When you update the runtime (change it from 22.08 to 23.08 in the manifest), all the dependencies are updated too. Many simple applications don’t depend on many more dependencies than are available in the runtime. Some…have more complicated dependency trees.
But counterpoint: the developer will update the dependencies when they are known to work properly with the application. Upgrading GTK3 to GTK4 in the GIMP flatpak will just break the application. Same thing with Krita and the dozens of patches to libraries it depends on. If you upgrade the application in the name of security before it’s compatible, all you end up with is a broken application. Which I guess is more secure, but that’s not helpful to anyone.
Which means that if you have a flatpak with an uncommon library and the dev stops issuing updated flatpaks because they get hit by a bus, you could be SOL with respect to that library. Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there’s usually someone who can take over.
In this case, you’re responsible for packaging it yourself. This usually means specifying the git URL and build options in the manifest. You can see Krita doing this in their manifest because they don’t depend on the KDE Platform, as they need much older dependencies. So they’re responsible for over 1000 lines worth of dependencies.
The Freedesktop Platform is essentially a distribution unto itself, and I don’t think there’s ever been a case of dependencies in that distribution not being kept up-to-date.
Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there’s usually someone who can take over.
Well…debatable. There were over 1200 orphaned packages in Debian last year, many of which had not been maintained in over 3 years.
I wonder how much work would be needed to make a “FreeDesktop Linux” complete OS, with the runtime + whatever it needs beyond that. Then when you install a flatpak, it’s just like installing, uh, I didn’t think this through tbh.
Well, if you think about it, the Freedesktop Platform is essentially a distribution. And Flatpak used to be called “xdg-app”. If you’ve got all your graphical applications installed via Flatpak, with GNOME, Systemd, glibc, GRUB and all the core dependencies only packaged for the base system (essentially Arch’s core repository), that’s pretty much a Freedesktop OS.
Hey, maybe we could use Snaps for the base system and Flatpaks for the userland? Or are these the kinds of ideas that get people stoned?
Common libraries like OpenSSL are usually bundled in runtimes. So if my application uses e.g. org.gnome.Platform, I don’t have to update my application if there is a fix in a library of that runtime, I just need to update the runtime.
The runtime is also shared by all applications that use this runtime.
Flatpaks won’t get their libs updated all at once by just updating a library. This can be very bad in cases like bugs in openssl. Instead of just updating one library and all other software benefiting from the fix, with flatpaks, you need to deal with updating everything manually and waiting for the vendor to actually create an update package.
I’m not 100% sure about this. Flatpak has some mechanisms that would allow to manage dependencies in a common fashion.
Most Flatpaks depend on the Freedesktop Platform runtime, or GNOME/KDE runtimes, which are derived from it. This contains several hundred common dependencies and librarires programs need, like
gccandpython. When you update the runtime (change it from22.08to23.08in the manifest), all the dependencies are updated too. Many simple applications don’t depend on many more dependencies than are available in the runtime. Some…have more complicated dependency trees.But counterpoint: the developer will update the dependencies when they are known to work properly with the application. Upgrading GTK3 to GTK4 in the GIMP flatpak will just break the application. Same thing with Krita and the dozens of patches to libraries it depends on. If you upgrade the application in the name of security before it’s compatible, all you end up with is a broken application. Which I guess is more secure, but that’s not helpful to anyone.
Which means that if you have a flatpak with an uncommon library and the dev stops issuing updated flatpaks because they get hit by a bus, you could be SOL with respect to that library. Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there’s usually someone who can take over.
In this case, you’re responsible for packaging it yourself. This usually means specifying the git URL and build options in the manifest. You can see Krita doing this in their manifest because they don’t depend on the KDE Platform, as they need much older dependencies. So they’re responsible for over 1000 lines worth of dependencies.
The Freedesktop Platform is essentially a distribution unto itself, and I don’t think there’s ever been a case of dependencies in that distribution not being kept up-to-date.
Well…debatable. There were over 1200 orphaned packages in Debian last year, many of which had not been maintained in over 3 years.
TIL about bus factor
Thanks for the interesting point! I learned something today. I guess it all depends on your use-case, whether flatpaks make sense or not.
I wonder how much work would be needed to make a “FreeDesktop Linux” complete OS, with the runtime + whatever it needs beyond that. Then when you install a flatpak, it’s just like installing, uh, I didn’t think this through tbh.
Well, if you think about it, the Freedesktop Platform is essentially a distribution. And Flatpak used to be called “xdg-app”. If you’ve got all your graphical applications installed via Flatpak, with GNOME, Systemd, glibc, GRUB and all the core dependencies only packaged for the base system (essentially Arch’s
corerepository), that’s pretty much a Freedesktop OS.Hey, maybe we could use Snaps for the base system and Flatpaks for the userland? Or are these the kinds of ideas that get people stoned?
Common libraries like OpenSSL are usually bundled in runtimes. So if my application uses e.g.
org.gnome.Platform, I don’t have to update my application if there is a fix in a library of that runtime, I just need to update the runtime.The runtime is also shared by all applications that use this runtime.