The Definitive Solution to the Fedora Flatpaks Controversy

Project Discussion
,
1

It’s clear that Fedora Flatpaks have generated a lot of frustration, from quality concerns to duplicated work and confusion about direction. It’s time to turn that energy into something positive and sustainable.

Here’s a better path forward:

  1. Work with Flathub to create a FOSS-only filter for trusted, verifiable apps.

  2. Add a security tag that lets users filter by safety, reusing Flathub existing security metadata to avoid reinventing the wheel.

  3. Use Fedora Flatpaks as mirrors of Flathub if necessary, ensuring reliability and continuity without duplicating the same apps, only build unique Fedora packages when needed.

Fedora 43 showed how divided focus can hurt overall quality. If the plan is for immutable editions to become the main Fedora experience, then aligning efforts with Flathub makes even more sense. Collaboration is simply the smarter path forward.

Fedora has always represented innovation, freedom, and community. Let’s embody those values again, by working with others instead of duplicating their work.

Many of us will be watching the results of this discussion and what the Fedora Committee decides next. This could be a defining moment for Fedora’s future, and for its users.

Poll: What should Fedora do about Flatpaks?

  • :white_check_mark: Work with Flathub (FOSS-only filter, reuse existing security metadata, mirror model)
  • :gear: Keep developing Fedora Flatpaks independently
  • :prohibited: Drop Fedora Flatpaks entirely
  • :ballot_box_with_ballot: I don’t use Flatpaks / No opinion
0 voters
3

That’s exactly why I’ve been proposing the idea of having a Flathub mirror within Fedora, it could address both sides of the concern.

It would eliminate duplicated effort while still providing a reliable backup in case something ever happens to Flathub. At the same time, Fedora could actively collaborate with Flathub to implement FOSS and security tags, which could later be integrated into GNOME Software for better transparency and user trust.

But I’ll be honest: if the alternative is to prioritize Fedora Flatpaks over Flathub, I’d rather see Fedora Flatpaks disappear entirely. That would mark the end of what makes Fedora great, because no reasonable user would choose a repository full of buggy, feature-limited apps when so many other reliable options exist.

4

A FOSS (only) filter is not (by itself) sufficient. There needs to be a filter that says it contains no encumbered IP (i.e. the codes in the flatpak would be accepted into Fedora proper).

1 Like
6

Uhm,
I think you need to take a look at what flathub actually does and how its actually built before you can seriously propose anything of this nature.

For example.. just start with figuring out how you can rebuild the GNOME runtime and SDK locally. Because as of right now its still not clear to me how to pull the exact corresponding sources from flathub and rebuild several of the primary runtimes using nothing but the information available from flathub.

There are serious concerns about rebuildability of the flathub contents that have to be addressed before your proposal becomes reasonable.

7

What information is missing in the official documentation?

1 Like
8

Hi Jeff,

I understand your concerns about Flathub’s rebuildability, that’s a fair point. But even with those challenges, the goal isn’t to depend blindly on Flathub; it’s to collaborate directly so we can fix those issues transparently and together.

If rebuildability is the main concern, it’s worth noting that Fedora Flatpaks don’t fully solve it either, many are automatically generated from Flathub’s manifests using scripts that parse its API. So Fedora already relies on Flathub’s work, just indirectly and without improving the process. My proposal actually addresses all those issues, reproducibility, transparency, and upstream collaboration, instead of duplicating effort.

You can’t cover a storm with a lid, the community’s frustration with Fedora Flatpaks is real, and even projects like Bazzite @kylegospo @castrojo , one of Fedora’s best chances to shine, are unhappy with the current direction. Revisiting this with an open, cooperative mindset, seeing Flathub as a partner, not a rival, would show true leadership and strengthen Fedora’s future.

9

On of those issues is rebuildability as it pertains specifically to the requirements set forth in the GPl and LGPL licenses that much of the runtimes depend on. You have to remember unlike the apps, the runtimes are an aggregate of dozens, maybe hundreds of individual projects, representing hundreds maybe thousands of individual contributors that contributed code under agreements set forth by the GPL, LGPL and other licenses. It’s not clear to me, yet, that the runtimes at flathub are respecting those agreements. And that’s a problem that needs to be solved… its sort of fundamental actually from my pov.

And back in July, I was actually having good conversations about that.. that resulted in Timothee writing up new documentation at flathub on how the source publishing works to address most of my concerns when flathub builder is used. I thought we were having a good discussion, leading to solid documentation on the existing tooling that the application flatpaks mostly use. The tooling isn’t perfect, but its a solid foundation for the app flatpaks where there could be cooperation to further enhance the tooling. Which reminds me, I need to follow up on the deficiencies in flatpak builder, its on my list.

Unfortunately that only seems to apply to the applications that use flathub builder, things built inside flathub infrastructure. Some of the critical runtimes are built elsewhere using other tooling and published at flathub. Its the runtimes I’m focused on right now. Its the runtimes that are critical to the operation of flathub, because the are critical shared dependencies for the operation of a significant portion of the open source applications at flathub.

I am doing the work to discuss the issues as transparently as possible. Unfortunately at GUADEC I found something that multiple people agreed on I shouldn’t talk about, and it took 3 months for my embargo to be lifted. And now I’m back and ready to continue talking about the issue of source availability and rebuildability. I’m ready to continue to do the work as transparently as possible.

There is a high likelihood that I will find more problems of a sensitive nature on this journey, and I will be embargod again, simply because what I am trying to address may be tied to legal liability for flathub as a distributor and I need to be sensitive to that. I want the problems addressed. I’m hoping the next thing, if it comes, results in a shorter embargo. Sitting out on the material public discussions for 3 months is difficult. I’m not interested in watching flathub get actionable C&D letters based on things I find… that’s the last thing I want. If anything I want to make sure flathub doesn’t get blindsided by an actionable C&D concerning any GPL or LGPL code in the runtimes. If they had to pull any of the runtimes down in response to something like that it would be highly damaging, possibly crippling, or at the very least inconveniencing to application developers and users. I want to fix the underlying problem, so the possibility of that grows increasingly less likely.

I’ve reviewed the fedora flatpak process.. its also not perfect. But because all the fedora flatpaks are just rpm content, we have a coherent source availiability story. I’m pretty confident I can grab the corresponding source for a fedora flatpak, patch it and rebuild a replacement flatpak for my own use if I need to. Even the Fedora runtime flatpak which is composed from dozens of rpms. I should poke someone about writing something up from the pov of someone who needs to do a local patch and build of a fedora flatpak so we can have a cleanly documented example for everyone. But because we already have that story for fedora rpms, I’m confident that we can write that up into something coherent for the entire collection.

I’ve no idea how to even imagine doing something similar for the runtimes ive looked at at flathub in this moment. It would be great if someone who feels they understand flathub better than i do, took a stab at that. Just attempt it and write up your findings. Your a user and you want to patch the gnome runtime flatpak and use your local patched copy. How do you do that right now? How do you do it in a way that you’re confident that the sources you are starting from are the sources that were used to build the binary distributed by flathub?
I don’t think its possible to actually do that at present. I would love to be proven wrong about that.

10

I think the best option would be to split fedora flatpak into two repositories: one containing core apps and another extended

The core would be enabled by default, and the extended and Flathub FOSS would remain as options within Fedora Third-Party (user choice and responsibility).

Fedora third-party will be improved so users can enable all of the repositories or enable them separately.

11

You know…
that’s an interesting alternative approach to the filter proposal that on its face appears to reach the same goal. It would be interesting to get Timothee’s perspective on that as the proposer of the targetted filter to see if this would work from his perspective.

We’d have to think about how things transition from one to the other.. because what core apps were would not be static over time and as our collection of bootc based outputs grew or shrank, there would have to be a way to propose apps move across that boundary both ways. But that’s probably worth sketching out in a more comprehensive straw proposal.

12

The difference is that the filter excludes other non-core apps. With two repositories, however, the user has the choice to enable/disable the extended.

It’s similar to the Graphene OS Android, which has a store for the default applications that come with the system. Users have the freedom to use any store they want, such as sandboxed Google Play, Aurora, or others. Fedora is gradually transitioning from a distro to a complete system (I don’t know how to express the idea well), giving users the choice to download software from they want.

As for changes to core applications, this is for workstation WG, KDE sig and others role

13

I’m going to try one more time to communicate my concern about the split. And if I’m still not making sense to you, then let’s chalk it up to me being unable to accurately express my concern so we don’t let this be a hang up on you feeling empowered to explore this idea further with the people you need to.

First let me say, I think your idea has merit and I think it should be explored as a possible future.

My one concern is that I see a future where the concept could be gatekept in a way that is inappropriate, because I see a possible future where additional bootc outputs, under the banners of Fedora spins and remixes will want to have different out-of-the-box applications than the larger more popular general purpose items. I don’t want to build a future where those possible future things are constrained unfairly because of decision making of the more popular general purpose outputs that exist now. I want a framework that anticipates more than the requirements of the outputs that exist right now.

14

Thanks for clarifying.

We may return to the first method with some changes, a repository with a filter or sub-set containing only the core apps for each spin (each spin has its own filter), which is enabled by default, and the full repository is an option for the user.

As for the rest of the distribo that rely on Fedora, such as ublue, I don’t think they want Fedora flatpack, nor are they under Fedora’s responsibility.

15

But to be clear, I’m not talking about the downstreams that live outside of the Fedora Project. I’m talking about the space inside the Fedora Project for where alternative opinionated outputs can live.

Fedora Spins are my chief concern in my thinking here, because Spins make a commitment to use only Fedora software, they will need similar consideration in what is and is not a core app as do the flagship edition outputs. Because Fedora Spins could conceivably preinstall anything to achieve the user experience they are aiming for, there is a possible future where there is a need to expand the core apps to include every UI application that Fedora packages as an rpm.

But I am also concerned about how we treat Fedora Remixes, which are in an in-between space, and is why the Fedora Project has specific branding for their use, if they choose to associate with Fedora at all. There may be Fedora Remixes derived from official fedora bootc base images in the future that want to have core flatpaks apps from Fedora, there may not, I have to have a framework that anticipates that there will be. The EU OS effort is one downstream that can be considered a Fedora Remix that I know about right now that has a desire to use fedora flatpaks in a maximal capacity..so I’m not expecting the core versus extra split will matter to them, they will just turn on both remotes. But there may be others in the future that want consideration in what is in core versus extras.

I also have to take into consideration how bootc switch will work for users who want to jump tracks between bootc based Fedora spins. It gets complicated to think about.

16

Jef, since the poll results show a clear majority in favor of collaborating with Flathub and reconsidering the current direction of Fedora Flatpaks, I think everyone in the community deserves to hear your stance in an honest and straightforward way.

What do you think about these results?
And what concrete plans do you have in mind after seeing such a strong response from users?

We’re not looking for vague or indirect answers, we simply want to know whether the public’s opinion will genuinely be taken into account in the project’s decisions. The community has spoken quite clearly, and it’s important to understand whether that voice will have a real impact on what happens next.

17

I always saw the frustration with Fedora Flatpaks as a naming convention issue. As the user, if you tell me OBS on the Fedora Flatpak repo is not the full featured OBS, It would make that decision FAR easier.

I chose OBS for this example because it depends on things that Fedora would not be able to package. So calling it *OBS-By Fedora* and a quick explanation in the description about FOSS, would solve my problem. Calling it OBS and have missing functionality is not ideal. It’s like asking for Iced Tea and not getting Ice, when you clearly asked for Iced Tea.

This same issue is present in other distros, as in the Debian KeepassXC build they also removed functionality but made no indication of it nor did they make an attempt to tell the user that functionality is removed.

The Fedora repos’s should tell the user this is a FOSS based version of XYZ software. To also expect functionality to be removed, not present.

18

Jef gave his view many, many times in this thread: Some Fedora Flatpaks re-use Flathub app's manifests without crediting the authors

This poll result changes nothing. There are real legal and quality concerns Jef outlined in his many posts.

The changes that Fedora would like to see made to Flathub before Fedora considers more closely integrating Flathub into Fedora do not need to be made by Fedora.

If you would like to see Flahub in Fedora, I would strongly recommend volunteering your time to improve Flathub.

3 Likes
19

Fedora very likely has more than 44 users :stuck_out_tongue:

2 Likes
20

Following that logic, I guess elections in countries where the winning option only gets around 40% wouldn’t be valid either, right? That is how democracy works, imperfect, but still the best representative measure of what the majority thinks. What’s the alternative? Ignoring the community entirely so that two or three people make all the decisions? That’s not collaboration; it starts looking a lot like a dictatorship.

And honestly, after reading your replies in @tragivictoria post, it’s pretty clear you’re not really aware of what’s going on with Fedora Flatpaks, especially considering comments like “Are they non-functional? Or what’s badly packaged about them?” That alone shows you’re not using Flatpaks regularly, and on atomic systems Flatpaks are absolutely central. So it’s strange to dismiss the concerns of the people who actually depend on them daily.

If we’re talking about representation, just look around: Brodie Robertson’s videos are full of people supporting dropping Fedora Flatpaks, and the same sentiment appears across forums, Reddit threads, and posts like Victoria’s. The majority preference isn’t exactly subtle.

So if the community’s voice isn’t going to matter here, then genuinely, what’s the point of having these forums at all?

21

Poll it where majority of actual users can vote on it (similar to GNOME’s donation notification thing)

22

@linuxkernel94 @Espionage724

The thing is, the poll results are completely meaningless. The problem is not that Fedora believes users hate Flathub. It’s the opposite, many prominent contributors of Fedora want Flathub too.

It’s just that Fedora has certain principles and requirements. It would be nice to raise Flathub to better match Fedora’s security and reproducibility wants/needs rather than just accept Flathub as is. And if Fedora accepted Flathub right now, there would be less motivation for addressing those issues.