I just thought it would be a great idea if KDE runtimes for flatpak would be rolling, with version of packages matching the ones in arch repos. Maybe it was your idea all along?
That way, runtimes would not be required to be downloaded separately and could be a part of the immutable system image. Is it actually the case?
Basically the idea envisions using Flatpak runtimes as content for the base OS, such that we could put most of the GUI software in Flatpak, including Plasma.
That way, the base system would really just be a minimal bootloader and bootstrapping system for launching KWin, the login manager, and Plasma.
We’re a long way away from making that a reality though — if indeed it’s even a good idea.
Yes, that is the problem. However, my solution was not listed in the list of options available. I added it 
No, I propose the other way around - to get rid of runtimes since all the files are already found on the base system.
Flatpak apps can’t get their libraries from the base system; they have to be in a runtime. Runtimes constitute an inseparable part of Flatpak as a technology.
Yes, changes would be required for flatpak
It’s not only deduplication that matters. It is less burden of maintaining runtimes (since versions are the same as in the distro). And it is rolling-distro model that is instilled upon app developers
How would the Flatpak developer provide assurance that their application would work cross-distro, if different distros have different runtimes?
The model of Flatpak is that the developer stipulates a single runtime and version that the application must run on.
If we say that a Flatpak application needs to run on different runtimes according to what distro it’s running on, we lose a big advantange of Flatpak. It’s much harder to guarantee the app is going to work correctly if it has to support multiple runtimes.
all distros would run the same runtime which will contain libs with versions matching arch repos
probably on arch linux this runtime could be quickly constructed with hardlinks to files on the base system
And there’s only one (rolling) version of that runtime?
So if I write a Flatpak app, I can’t force it to run on a specific version of the runtime? Then an app which works today could get broken tomorrow because a package in the runtime changes.
yes, it will break, it is your duty to update the app. A natural thing for archlinux users. But you may bundle whatever deps you want and depend less on the runtime
Thanks for explaining.
I myself would stop using Flatpaks if this change was made. That’s too much instability risk for me.
You’re free to propose it to Flatpak of course
That’s not accurate. Not all files are found in the base system. Often developers have to add their own dependencies in their flatpak manifests because those are missing from the runtime.
(Removed the Kirigami Addons example because it’s an example of something added manually to manifests, but not something missing from the base system)
Basically this can’t work. Flatpak apps that get their dependencies from the base system rather than a runtime… aren’t really Flatpak apps. 
The technology doesn’t and can’t work this way, and if it did, it would remove a major advantages of Flatpak, which is that the runtimes constitute a real and predictable platform.
I’m quite confused, sorry if I completely misunderstood.
Is the idea to make the KDE Flatpak runtime the same as kf6-core?
kf6-core is the content Snap used when adding the “kde-neon-6” extension to a Snap app.
If I’m not mistaken, it’s built using the KDE Neon repository as a base, so it has recent versions of QT and KDE.
This means that if apps use the “kde-neon-6” extension and are on core24, they will all use the same runtime: kf6-core24.
Whereas in Flatpak, there’s a runtime for each QT version, if I’m not mistaken.
No, it would takes deps from the base system only on banana linux, on other distro it wouldn’t.
Anyway, stupid idea