It’s a weird idea but I want to share it. What if we had rolling runtimes for flatpak? Yes, the runtime itself and the apps would be required to be updated more often, but this is the way of a rolling distro. It’s counter-intuitive but it works.
The bonus for a rolling distro like arch would be that a runtime would be just a collection of packages and won’t be required to be downloaded separately.
Another idea is to have a distribution (like GnomeOS) with versions of packages matching the ones in runtime. That way the runtime also won’t be required to be downloaded separately. But it seems it doesn’t work too well: for example, KDE is moving from KdeNeon to Arch (Banana Linux)
GNOME apps are generally synchronized with the GNOME runtime.
What do you mean by “rolling runtime”? Updating the runtime with each new major version of a library? This isn’t useful for GNOME libraries. External libraries, on the other hand, have stable versions with security fixes, and updating to a new major version without testing is not recommended, as it could, for example, break API.
Why do you use FlatPak? Just build statically linked runtime inside binary - Look my thread but it works fine for latest version since 4.20.x and 4.21.x But you should add credits with Gtk4 by Gnome and statically linked by me. ) But I want to support everyone…. without stressed runtime’s installation or problem with FlatPak.
You see that - cause some user stress about older or newer version under Linux systems.
But I solved problems with portable linux application with statically linked runtime with Gtk4, Glib-2.0, Cairo and Pango inside binary. It is easy. But I won’t violate licensing terms.
Although I’m not a developer, I don’t see any connection between the latest major version of libraries and static linking. If the libraries don’t have API breaks, bugs, or anything else that could affect an app, of course, in most cases, this shouldn’t cause any problem. However, developers should still test their app to ensure it doesn’t have any regression.
It does not work. The whole tradeoff of the runtimes is that we get a collection of core utilities we all need, but the ABI doesn’t change so it can always be updated and done so independently.
Without this guarantee/tradeoff your applications will either break on their own cause suddenly a symbol or library will be missing from the runtime, or alternatively, you will need to rebuild/recompose and retest the application for every application update.
This is a false assumption. First of all, the Runtimes and Host OS are most often different binaries. Unless it’s GNOME OS where it’s almost identical to the GNOME Runtime. But even then, the runtime can and will be updated independently, and thus you will have again duplicate binaries. Even if you had a magic mechanism/storage where you’d be able to share the OS and Flatpak binaries, they will still almost never much and you will always have to reserve the extra space.
—-
Slightly unrelated: We have a “rolling” version of the GNOME Runtime, we call it Nightly. It contains versions of all the modules from daily git snapshots. It breaks often and its only useful for development and testing, at no point is it something that should be shipped into users.