Yes and no. Yes, because I do use their software and no, because I do use flatpaks.
I’m sorry that I’m not gonna address all of your comment (it’s, um, a lot of text and i’m extremely tired), but my point essentially boils down to: apps using EOL runtime are not a serious issue. It’s a minority and if app is really old (just like it happened with Nautilus on Flathub) users would only be able to download it via CLI. What happened with OBS was an unfortunate situation, but to say something as if the app was badly maintained (or other similar things that were said) is just cruel. Note that it was indeed a temporary solution and since some version (idr which one) OBS is back to using latest runtime.
Banner informing users that the runtime is EOL in GNOME Software is indeed lacking, but maybe there will be some volunteer willing to send a patch fixing this.
its almost 2 o clock, so please excuse my spelling and/or my grammar. hopefully i succeeded at conveying what i wanted to say
What if I told you that there were at least 1000 apps at flathub that are using EOL’d runtimes? Would you consider that insiginficant?
without a concise list of what the currently supported runtimes are I can’t do a full accounting. And that list doesn’t exist as a documented artifact of flathub policy afaict, and the tooling doesn’t let me discover what is EOL’d what is not afaict, othe than by trying to install everything one by one and recordingly which flatpaks trigger a warning message.
But just looking at the stats page for flathub and doing something naive like counting up everything running an older version of any versioned runtime as potentially an issue then the numbers add up to be a significant percentage of the flatpaks. But that’s not accurate enough. because what matters is which of those flatpaks have been updated since their runtimes went EOL.. and I can’t get that from the stats page because it doesnt give a sense at all of what flatpaks are being actively updated and which ones have gone inactive.
I’d like to do an accurate accounting what the state of things are.. but its not clear to me if there is a way to ask the tooling for the information necessary to get solid numbers using a methodology that others can repeat for themselves.
You raise a valid concern — the state of runtimes in Flathub deserves better visibility and tooling. But I’d argue that this shouldn’t block enabling Flathub by default for FOSS apps in Fedora.
A few thoughts:
Even with the current issues, the value of giving users access to thousands of actively maintained FOSS apps outweighs the downsides of the minority using EOL runtimes — especially when the alternative is no access at all by default.
The problem of EOL runtimes exists regardless of whether Flathub is enabled by default. What we can do is help surface that issue better in GNOME Software (as Victoria mentioned), and collaborate upstream on improved metadata or tooling.
Fedora enabling the FOSS-only filtered Flathub could actually push momentum toward cleaning things up, by putting more eyes on the problem from a more diverse user base.
In the case of OBS and others, things did get resolved — and that’s good! But many users don’t know Flathub even exists or how to enable it, so they never even get that far.
The toggle to enable full Flathub (for nonfree apps) would still be present post-installation and in GNOME Software, just as it is today.
So in short: yes, the EOL runtime issue is real — but solvable — and not a strong enough reason to block Flathub (FOSS) from being default, which is a necessary step for usability, interop, and the future of Flatpak-based systems like Atomic desktops.
Thanks for raising the quality concerns — let’s keep pushing for better tooling and better defaults.
You are wrong. Use of an unmaintained runtime is dangerous and irresponsible professional malpractice. This is a very serious issue. Flathub needs stricter rules before this proposal to enable it by default should be accepted. E.g. Flathub previously prevented developers from releasing app updates if the runtime was unmaintained; simply resurrecting that rule would be a pretty good start.
OBS Studio was a particularly egregious case, one that unfortunately significantly undermined my faith in app developers. The excuses for why it could not use a maintained runtime were unacceptable, and citing it as an example helps my argument, not yours.
Possibly, but my goal is to improve Flathub, so I certainly don’t want to ignore the problem. We should solve this before enabling it in Fedora.