eg. change this:
runtime: org.gnome.Platform
runtime-version: "46"
to this:
runtimes:
- org.gnome.Platform/46
- org.gnome.Platform/45
- org.freedesktop.Platform/20.08
- org.kde.Platform/5.15
Many people complain about flatpaks taking up too much space. Allowing for more runtimes to be shared between apps would take up less space. However, this has been denied.
If I am an app developer and I know my app runs on several different runtimes, why shouldn’t I be able to specify all of those runtimes? Are there technical reasons why this is a bad idea?
EDIT: I mean a list of runtimes of which one must be installed, not a list of runtimes of which all must be installed.
To answer the question of “why not” we only have to ask “what problem are Flatpaks meant to solve”:
- Flatpaks allow applications to run identically on different distributions
- Flatpaks reduce the burden for software providers having to support multiple environments
The way that Flatpaks achieve these goals is precisely by mandating the environment that the application will execute within.
Allowing the application to run in different environments goes directly against two core value propositions of the project.
Being resource efficient is not one of the primary goals of Flatpak. Providing a consistent and deterministic execution context is.
There is your answer.
I am sympathetic to the question and the desire though. This is one of the reasons I do not like Flatpaks. Dragging in these big environments, and the duplication of resources, feels very wasteful to me. I would like them even less though if they did not even deliver on their core promises.
Personally, I prefer Distrobox to Flatpak. At least I have more control. Arch / AUR in a distrobox will let you install pretty much any app on any distro. If the app you need only runs in one distro ( like Ubuntu ), you can create a Distrobox of that too.
We could take this further and let developers specify exactly the dependencies they need! No more bloated runtimes! App A could specify libfoo>=1.23.45 while app B specify libfoo<1.24 and Flatpak could resolve the compatible version automatically!
Serious answer: If space saving is the goal, traditional packaging is the way to go. Allowing multiple runtimes is a slippery slope away from the core idea of Flatpak (simplest dependency management possible so developers don’t have to test many configurations).
(Not that there’s anything wrong with traditional packaging with more complicated dependency management - it’s just not Flatpak’s thing).
Good Idea in theory, but i think it would fall short because
- supporting multiple runtimes requires more develeoper effort, if even possible
- a single app is enough for a runtime to be required to be present. So it’s unlikely to save space
- The number of possible runtimes isn’t that high anyway. I think the flatpak folder on my pc is like 10GiB.
What if there are breaking changes in a runtime between two versions?
And what sense would it make to define several different runtimes to begin with? Does your GTK application uses QT code and vice-versa? Or am I interpreting this wrong?
And what sense would it make to define several different runtimes to begin with? Does your GTK application uses QT code and vice-versa? Or am I interpreting this wrong?
Yes sorry, it took me a while to understand what you were asking. I didn’t mean specifying a list of runtimes that must be installed. I meant specifying a list of runtimes of which every one would be suitable.
What do you need 45 for if it runs with 46? Update the app that’s still on 45 instead of making sure yours runs with an outdated version.
Space is one of the least concerns for me on a computer, even if it is a phone.
Say you have 8 apps that require 45 and you download one that requires 46. Now you have two environments. If the new one worked on 45, you could continue with one.
I am not advocating their position but that is what they are asking for.
It could be interesting if it stuck with the most recent that all apps support. So, if all the apps supported 45 or 46 then the system would use 46 but if one of the apps only supported 45 then it would hold the rest back to 45.
The idea with Flatpaks though is that they behave the same on all distros. So think it is better to force the right environment. It does make Flatpaks wasteful though which is one of the reasons I try to avoid them personally.
I use a distribution with lots of packages that are generally up-to-date so Flatpaks are not solving a problem for me. For most other distributions, they fill a real need. There are downsides though and this duplicated environments issue is one of them.
A runtime is about 1GB, that’s 100 photos or a 2 minute video. I don’t worry about such things. Flatpak’s size is no problem.
Apps become outdated, or at least don’t get updated in time. You’re stuck on old runtimes because you want to save 1 or 2 GBs.
If you want to save space, update the outdated app. If everything is included in 46 and nothing changed, updating is straoght forward.
What do you need 45 for if it runs with 46?
If someone has 45 already installed and then installs a new app that supports 45 and 46, one would not have to download 46.
You have to download 46 eventually anyway. What if there’s a bug in 45? Why should you stick to 45 with the newer app? There’s no reason in sticking to older versions other than stability. Runtimes are stable enough.
The question was, “why is this a technical limitation?” Not, “what should I do to work around the limitation?”.
OP is trying to solve no problem. I just keep her from wasting her time.
You are the only one wasting time by giving dumbass avoidance advice instead of telling us what you know.
… What insider information do you have and why do you want to keep us ignorant???
