I have been updating end-of-life runtimes sometimes and marking abandoned ones as end-of-life.
Flathub created an end-of-life policy (Maintenance | Flathub Documentation) some time ago, and I have created several issues to inform maintainers and marked really old ones as end-of-life, following the end-of-life policy.
Mailaender says:
I thought Flatpak/Flathub was supposed to be an isolated time capsule for software, so these deprecations are a major bummer.
Source: End-of-Life Notice · Issue #10 · flathub/net.warsow.Warsow · GitHub
So, what I want to know is: what is the standpoint on software preservation, and how can we keep using end-of-life runtimes without marking some Flatpaks as end-of-life even though they are many version behid of a supported runtime?
Keeping an application on an EOL runtime is not a good idea in my view.
First, there is the general rule that you should fix security issues by applying updates. One could argue that this isn’t that big of an issue if you don’t use many permissions, like the game that opened this discussion. But it also is a bad precedent, both for sloppers whose LLM gave them an EOL runtime for their submission and for users.
Second, while Flatpak is good in deduplicating, any additional runtime will still need more space. This would only grow more the more the old runtimes are out of sync with the current one.
Now, as for the software preservation argument:
Arguing with that can’t be the first resort. The Freedesktop SDK is updated once a year and most of the time it should be without too much issue.
At least testing the software with the current runtime should be possible for the maintainer. Otherwise it isn’t really maintained IMHO.
I don’t want to throw old games out because their complete. I also don’t want to give too much burden on maintainers. But I also don’t want to advertise software that is unmaintained to users either.
Just my two cents.
Flatpak can be used for software preservation. We won’t ever delete old runtimes or EOL-ed apps unless required for legal reasons.
Software preservation isn’t the goal of Flathub.
Flatpak != Flathub
Preservation can be both valuable and also “not a good idea,” as the systems still running COBOL show. One thought: Maybe an OS container is a better preservation approach than keeping a ton of old platforms on flathub?
Leaving preservation aside, it would be a good idea if developers whose software gets packaged as flatpaks updated their code so that we can leave older runtimes behind. I’m rather new to this, so everything I say is blitheringly obvious.
How many still-needed versions of org.whatever.Platform are reasonable? They take up space and chew up bandwidth with refreshes/updates. For the sake of argument, I’ll hazard that three “branches” of each runtime is somewhat reasonable, but that fewer would be better.
The Why Flathub page states some purposes or goals. Then there are goals of flatpak packaging, irrespective of repository. Flatpak.org doesn’t help much with that, but the flatpak man page enunciates goals (host independence and sandboxing):
Flatpak is a tool for managing applications and the runtimes they use. In the Flatpak model, applications can be built and distributed independently from the host system they are used on, and they are isolated from the host system (‘sandboxed’) to some degree, at runtime.
What about “time capsule” software preservation, i.e., the ability to keep running an application long after its devs have wandered off? For example, many people want to run “legacy” games. Flatpak, snap and appimage packaging seem to offer tools that could facilitate this goal. But I doubt whether those building and maintaining packaging methods focus specifically on the goal of long-term software preservation.
Perhaps someone else can create a light weight LTS runtime for games, kinda like what Steam does?
Said LTS runtime will need maintaining.
Who will do it? The people who dont want to bump the runtime version of a manifest once a year?