Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime org.freedesktop.Platform branch 22.08 is end-of-life #117

Open
rusty-snake opened this issue Sep 24, 2024 · 5 comments
Open

runtime org.freedesktop.Platform branch 22.08 is end-of-life #117

rusty-snake opened this issue Sep 24, 2024 · 5 comments

Comments

@rusty-snake
Copy link

Info: runtime org.freedesktop.Platform branch 22.08 is end-of-life, with reason:
org.freedesktop.Platform 22.08 is no longer receiving fixes and security updates. Please update to a supported runtime version.

@salim-b
Copy link

salim-b commented Dec 30, 2024

#82 which would update the runtime to 23.08 has been open for over a year now... meanwhile, 24.08 has been released.

Is nobody maintaining the com.play0ad.zeroad Flatpak here anymore?

@rusty-snake
Copy link
Author

The most flatpaks on flathub are not actively maintained and shouldn't be used. I only use flathub-flatpaks where the developer recommends that flatpak distribution over "classic" distributions. There is just too much trash in it.

For 0ad I use the fedora flatpak.

@salim-b
Copy link

salim-b commented Dec 31, 2024

The most flatpaks on flathub are not actively maintained and shouldn't be used. (...) There is just too much trash in it.

I can't second that. On my Ubuntu desktop, I currently have 77 apps as Flatpaks installed, all from Flathub and as far as I can tell, 0ad is the only outdated one (at least the only one using an EoL runtime).

Of course, everything's most streamlined when the upstream developers care about the Flathub distribution themselves – sadly not all do (a popular negative OSS example being Signal devs). It's transparent on Flathub whether an app is maintained by upstream (or someone explicitly entrusted by upstream) via domain verification – so it's easy to avoid such unverified apps.

For 0ad I use the fedora flatpak.

Thanks for the hint! I've read up about Fedora's Flatpak remote, it seems to be

  • a) a testbed for OCI-format-based Flatpaks (specs), and
  • b) a means to push Fedora Linux since all Fedora Flatpaks are built from RPM's and use Fedora Linux as their runtime.

About the latter I have mixed feelings. It doesn't allow the upstream developers to maintain the Flatpak themselves – it's always built from the RPM – and it doesn't allow them to choose the Linux distro they'd like to base the Flatpak on – it's always Fedora Linux.

On Flathub OTOH, it's left up to the publisher to choose the Flatpak runtime. If they don't want to use any of the three official Flathub runtimes, they can simply bundle the dependencies themselves and/or build their own Flatpak runtime. Apparently, OCI containers can even be directly converted to Flatpak runtimes using tools like flatpod. If Flathub would make the switch from being an OSTree-repository to an OCI-registry remote, it would make using non-Flathub runtimes easier for app publishers at the price of increasing storage space requirements for users (since they more likely end up installing apps that use different runtimes).

Given the way richer and faster growing "cloud native" OCI ecosystem1, I could imagine that Flathub will eventually make that switch from OSTree to OCI container tech anyways.

The Fedora Flatpak remote is nice to have2, but certainly not a real solution to the underlying software distribution problem: As a user I'd need to also add a hypothetical Debian/Arch/Alpine etc. remote for apps that the Fedora project doesn't happen to maintain an RPM for – currently I count 333 (excl. runtimes) in Fedora's Flatpak remote vs. 2810 on Flathub3...

Footnotes

  1. Thinking especially about "atomic"/"immutable" Linux distros like Universal Blue and friends that are in the process of switching from libostree to bootc.

  2. Fair competition is what makes open source so incredibly innovative, after all. 😄

  3. Though I have to admit I couldn't find out how many of these are proprietary apps – a fair comparison would exclude them since the Fedora remote only hosts open-source apps.

@rusty-snake
Copy link
Author

I can't second that. On my Ubuntu desktop, I currently have 77 apps as Flatpaks installed, all from Flathub and as far as I can tell, 0ad is the only outdated one (at least the only one using an EoL runtime).

77 out of how many? Thousand?

Anyway maybe your lucky or I'm unlucky but my experience is more than half of the programs I used to install as flatpak went into EOL-runtime state at some point.

Also I do not only talk about EOL-runtimes but also about missing updates for new release of the application itself and most critical of dependencies.

Fedora Flarpak

Yeah, it solves some of the flathub issues and creates its own issues (you often need to fix static permission by hand for example).

@salim-b
Copy link

salim-b commented Dec 31, 2024

77 out of how many? Thousand?

Flathub currently hosts 2810 different apps, according to their stats. Growth looks pretty healthy, actually.

my experience is more than half of the programs I used to install as flatpak went into EOL-runtime state at some point

Yeah, it happened from time to time that other Flathub apps went into EOL-runtime state in the past for a brief period of time for me too, but they all got updated eventually. In my impression, the general situation got better over the last years and compared to the classical distro-specific packaging, Flathub is just incredibly well-conceived and really solves the Linux desktop app distribution model in an excellent way, both technically (via Flatpak) and organizationally (via verified and unverified publications, build moderation and automating as much as possible). What Flathub is obviously still lacking is maintainers for unverified apps.

it solves some of the flathub issues

The 0ad Fedora RPM is cherry-picking commits from upstream's development branch onto the latest upstream release (alpha 26) in order to be able to update dependencies. This is not a solution for app distribution but rather a workaround for a lack of upstream maintenance.

You can twist and turn it however you like: In the end, the underlying issue you're complaining about is caused by poor upstream maintenance of their latest stable Linux release (still called "alpha") and/or ignorance towards Flatpak, cf. #125 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants