An open discussion about Fedora runtimes distributed at Flathub

Hello everyone,
As promised, I’m starting a new thread focused on the discussion of a possible future involving distributing Fedora runtimes at Flathub, meant for application developers to target.

I’ll get this discussion started with my personal summary of some cordial private discussions I’ve had about possible futures and where I think things stand. I want to thank everyone who gave me their time over the last few months to have reasoned and sometimes passionate dialogue with me, exploring the benefits and difficulties of this idea.

First, let me say from my perspective as the Fedora Project leader, I think this is a great idea to try, for a number of really good reasons. But chiefly from my perspective, this would allow us to be participants in flathub in a more significant way and break some of the us versus them dynamics I’m seeing.

We technically can do it, I’ve had discussions in the context of my role on the GNOME Advisory board where its been made clear there is technically a space and it would be allowed. The Fedora flatpak runtime we produce right now, that serves our internal flatpak collection, probably wouldn’t suffice as is. We’d have to figure out a way to expose both a runtime and an SDK so people could use our runtime and build applications directly from sources, which is the expectation at Flathub. I don’t think this is unsolvable, I’m just saying there is some work to be done for here to adapt the runtime we have into serve both our internal and more general use cases.

So that’s the good news. The bad news…

From other discussions I’ve had, it’s also been made clear that what we could do right now might not be valuable as a runtime target for application developers. My current understanding, is that from an application developer’s perspective, a runtime at flathub.. must provide a stable ABI/API for the supported lifetime. I’m not sure Fedora can do that at present. I think we may have a soft ABI/API promise.. but a promise too soft for what Flathub application developers expect. Figuring this out is critical. There’s no point in building and distributing a runtime at Flathub if we can’t meet this critical expectation.

Beyond that, there’s the issue of relative value compared to existing runtime choices at flathub. I’d like to avoid positioning a Fedora offering at flathub as a direct competitor with the work being done to maintain and developed the existing runtimes there. My goal isn’t to displace existing output, but I’d like to add value to the flathub ecosystem and in doing so build a bridge between the two projects.

So this is a fuzzy value proposition discussion, and this is actually even tougher than the ABI/API discussion actually.

I think the obvious value prop are runtimes with longer EOL lifetimes. And this is something Fedora is not set up for. However, CentOS may fit there. And if at the end of this discussion here, consensus that a CentOS or even a Red Hat UBI runtime is a better thing to try, I’ll use my role as FPL to have the conversations in other places to see if I can get people excited about doing the work to make it happen. End of the day, no matter what approach works.. Fedora, CentOS or UBI I think finding a way for us as a distribution ecosystem to participate in what flathub is doing helps align the future paths for the benefit of users.. all users. I don’t have to squint too hard to see what we are doing already as building reliable runtimes. I think if we chose to do it, we could do that work both in our traditional outputs and distribute something at flathub as well that application developers would value.

And with that, I’ll open the floor for other people’s thoughts. If you think there is a possible future worth exploring, lets talk about figuring out which path to take, and more importantly.. figure out who has the energy and time to contribute and try something.

3 Likes

I would start by noting that Fedora’s policies already describe a feature-stable release model:

“Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues.”

“Updates should aim to fix bugs, and not introduce features… This necessarily means that stable releases will not closely track the very latest upstream code for all packages”

So the “soft” runtime stability (which I believe means no breaking changes, but new minor release series) in Fedora that exists today is largely an issue of maintainers not acting according to the policy.

Having said that, I think that following the policy literally would create a poor security posture.

But I’ve started to question how much difference actually exists between Fedora’s update practices and Flathub’s. I had previously believed that Flathub was strictly shipping the same minor release series for all components, for the life of a runtime, but I am looking at the commit history for Flathub runtimes right now, and I see minor version rebases… So I don’t know that there’s that much difference between what actually happens in Fedora and what actually happens in Flathub.