F44 Change Proposal: Filter Fedora Flatpaks Atomic Desktops v2 [SelfContained]

[jspaleta (Jef Spaleta)]

Filter Fedora Flatpaks Atomic Desktops v2

Wiki

Announced

This is a proposed Change for Fedora Linux.

This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Allow image based Fedora Desktop outputs (and only those), to self-determine if they want to make use of filters on the Fedora flatpak repository for pre-installed Fedora Flatpaks and enable FlatHub by default. If output maintainers choose to enable Flathub by default, they must use flatpak filters to ensure the the Fedora Flatpak remote is used for all pre-installed user applications (the ones pre-installed from the ISO and the runtimes).

Owner

• Name: [[User:jspaleta| Jef Spaleta]]
• Email: jspaleta@redhat.com

Detailed Description

With this change, we want to make use of Flathub flatpaks an explicit decision for each image based desktop output (ie. each Atomic desktop). Fedora contributors may package any application as Fedora Flatpak, but those Flatpaks will not be made available immediately to user of the desktops that have Flathub enabled by default, unless they are preinstalled applications. Users that want to have access to all Flatpaks from Fedora can remove the filter or add an additional remote definition that the filter doesn’t apply to.

Why not use just use Flathub Flatpaks instead?

Moving the image based Fedora Desktops to using Flathub Flatpaks would potentially require legal work and infrastructure changes.
Completely removing the Fedora Flatpak remote from the Atomic Desktops would mean that the default installation would appear very bare bone in terms of available applications.
This change is thus trying to reach a middle ground between those two options, keeping Fedora Flatpaks where they are necessary and using Flathub flatpaks to meet growing median user expectation and desire for upstream binary packages for the graphical desktop applications.

Which Flatpaks will be added to the filter?

The list of Fedora Flatpak enabled for the Fedora Atomic Desktops will be maintained by the Fedora Atomic Desktop SIG, with input from the desktops working groups (Workstation Working Group, KDE SIG, etc.) and the Flatpak SIG. We will populate the filter with the list of pre-installed Flatpaks (and the runtimes) in SilverBlue as a starting point.

Feedback

This is a second attempt at this Change proposal after being rejected in the F43 cycle. After some discussion, I felt there was some confusion with regard to intent and benefits of the first attempt and I wanted to take a second pass at this and try to get clarity on some things. The text in this updated version draws heavily from the first in terms of technical specifics.

The most material change in this second attempt is to reframe strategic benefit and to clear up confusion and to clarify that FlatHub does not have to be adopted by all image-based desktop outputs. The maintainers of each image-based desktop output are empowered to make a choice to enable Flathub by default or not. We already have a legal decision that its allowed from a compliance standpoint. This is a change proposal meant to make it technically possible to do so with the least amount of friction and confusion to users.

There are tradeoffs inherent in the decision on what the default flatpak remote should be. This is why this updated version of this proposal is explicit that its up to the maintainers of each image based output to make the choice as to whether to turn flathub on by default or not. Ultimately its the decision of users to decide which remote they want to use for which applications based on their own requirements.

But the entire point of flatpak as a technology is to give application developers and maintainers the ability to decouple applications from the base operating system. We need to create a space for Fedora outputs that want to explore and innovate on the promise of flatpak as a technology the ability to do exactly that..decouple the base os from the application layer. Making flathub the default for a subset of image based outputs makes that exploration possible.. for the slice of users who have self determined that they want to explore the image layer based approach.

But because of uncertainty with regard to compliance issues at present we can’t cut over fully and we need to make use of Fedora generated flatpaks for preinstalled applications until there is clarity on the compliance issues for pre-installed software by working with Flathub to figure out how compliance concerns can be satisfied in a reasonable manner.

Benefit to Fedora

• Less confusion for Fedora users who expect to use Flathub applications
• Less confusion for upstream developers when responding to bug reports about “their” Flatpak’ed application
• Stronger focus on what makes Fedora better: upstream contribution and collaboration with other communities
• More focus and testing on the Fedora Flatpaks installed by default on the image based desktops

Scope

• Proposal owners: Add a filter to the Fedora Flatpak remote that imaged based desktops could choose to include as part of compose.
• Other developers: image based desktop maintainers would need to choose to use the filter and enable Flathub by default in their image composes. This is a choice. Based on discussion I expect at a minimum SilverBlue would choose to make use of the filter.
• Release engineering: Should not require any release engineering coordination.
• Policies and guidelines: Should not impact any existing policy. Flathub has already been determined to be allowed to be enabled by default, this Change establishes a mechanism to actually do that.
• Trademark approval: N/A (not needed for this Change)
• Alignment with the Fedora Strategy:
  This aligns with an upstream first approach for graphical application development and more specifically with the intent of flatpak as a federated technology available for use by open source graphical application developers.

Upgrade/compatibility impact

This change is intended to apply to participating image Desktops users on update. Users that are using Fedora Flatpaks may have to update the filter to keep receiving updates or move to Flathub packages instead.

Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

How To Test

Remove Fedora Flatpak remote, enable filtered Fedora Flatpak remote, enable Flathub remote. Commands to be added here.

The implementation will likely look similar to previous work:

• https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
• https://pagure.io/fedora-flathub-filter

Once the change is implemented, new installation ISOs for the Atomic Desktops making use of the filter will let users test this more easily.

User Experience

Users of the Fedora image-based desktops that opt-in to enabling FlatHub by default will install applications via flatpak cmdline or from the GNOME Software and Plasma Discover store, and will get FlatHub Flatpaks by default. The set of core applications pre-installed by default on the system will be installed using Fedora Flatpaks and will be defined by the filter implemented as part of this Change proposal.

Users of other Fedora outputs will need to enable FlatHub and set up filtering accordingly as a post-install set of user-initiated actions.

Dependencies

Contingency Plan

• Contingency mechanism: Keep things as is
• Contingency deadline: Beta/Final freeze
• Blocks release? N/A (not a System Wide Change)

Documentation

We will have to document how to remove the filter or add an additional named flatpak remote definition for users that want to use all Fedora Flatpaks.

Release Notes

Last edited by @mattdm 2026-01-26T19:45:37Z

Last edited by @mattdm 2026-01-26T19:45:37Z

[system]

How do you feel about the proposal as written?

• Strongly in favor
• In favor, with reservations
• Neutral
• Opposed, but could be convinced
• Strongly opposed

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

[ngompa (Neal Gompa)]

I’m still really not in favor of this, and at least for Kinoite flavors, I definitely don’t want this because it basically screws us for non-x86 architectures.

But the crux of it for me is that it’s a philosophical thing: Fedora hiding its own outputs from users is a pretty dark signal, and I’m not really a fan of it.

There are also practical workflow problems because any application allowed through the preinstall filter can never be disallowed since doing so breaks their ability to receive updates (unlike DNF, there is no mechanism for auto-switching sources, handling package retirement, removing obsolete software, etc. for Flatpak).

If we even give this option, we need some pretty strong constraints in place, and I would personally not want to have it activate Flathub by default, and instead only do this filter+flathub if the Flathub source is enabled by the user.

That said, most of this issue is that GNOME Software doesn’t have a reasonable UX for selecting source priorities. This isn’t an issue on Plasma Discover, and users are able to select their source preferences right from Settings in Discover.

[yselkowitz (Yaakov Selkowitz)]

We’ve been through this before, and it doesn’t seem like anything has changed here. Under no circumstances should we be promoting third-party content over our own content, if we should even be promoting it at all. Once again, time would be better spent in making sure that any supposed deficiencies in Fedora Flatpaks are identified and fixed, and develop a better “marketing strategy” for them, rather than rehashing the same old arguments every six months.

[jspaleta (Jef Spaleta)]

In order:

1. This proposal does not lock in any specific image based output to using the filter. If SilerBlue wants to use the filter and Kinoite does not… this approach should be fine.

2. Hiding.. we are stuck in zero sum game mentality because the UI experience does not yet have a clear path to have multiple variants of the same application installed.. even though technically flatpak as a technology allows it.

The technical path out of this trap is to have a clear path forward on application name spacing so that its possible to have multiple remotes or even a common remote that install variants of the same applcation in visually non-conflicting ways.

flatpak at the commandline makes it possible… flatpak as integrated into desktop files (which in the scope of this discussion is a legacy technology relative to flatpak) doesn’t expose flatpaks native capability to allow multiple variants of the same thing to be installed side by side.

As soon as we have a desktop user oriented way to install and access flatpak variants.. we can go crazy and have copr-like federated remotes that don’t conflict.

3. The workflow problems are inherent in flatpaks regardless of the remote in use by default.

4. I disagree… This change already a compromise whose intent is to make it possible to enable Flathub by default for outputs that want to enable flathub by default. If output maintainers do not want to enable flathub by default.. they dont enable flathub by default.

5. Thank you for the contrast between KDE and GNOME UI store featuresets. Not sure its germane to the issue of making it possible to enable FlatHub by default while meeting compliance requirements for preinstalled applications.

[jspaleta (Jef Spaleta)]

Let me be very clear…I did not mention any deficiencies in the fedore flatpaks.

The text barely mentions fedora flatpaks at all really.

This is about using flatpaks a distribution technology as intended..which is to decouple the base OS from the application layer… not about getting into a tit for tat on deficiencies.

I actually think the way we fedora flatpaks are managed now is structurally wrong for the technology because how Fedora flatpaks is managed now does not decouple the base os from the application layer in any meaningful way.

If Fedora flatpaks were rolled out of rawhide checkpoints and consumable on all fedora and centos releases.. that would be way more interesting and more inline with what flatpak as a technology is suppose to be doing.

But there’s also other things the fedora flatpaks could be doing.. like really focusing on trying to push the ball forward on the portals and taking a hardline stance on what static permissions were asctually allowed to be used. That would be compelling in terms of pushing flatpak as a technology forward..and not just respinning rpms into a new package format because its easy to do.

I’m actually going to be trying to start a public discussion about distributing a CentOS platform or UBI based runtime at FlatHub as a way to further explore the idea of decoupling the base OS from the application. I keep asking people if there is value in publishing the Fedora flatpak runtime as a target for upstream developers, and I can’t get anyone to agree that there is because of the relatively short support lifetime. That’s a signal that how we are approaching this technology is out of alignment.

[ngompa (Neal Gompa)]

@jspaleta

I’m actually going to be trying to start a public discussion about distributing a CentOS platform or UBI based runtime at FlatHub as a way to further explore the idea of decoupling the base OS from the application. I keep asking people if there is value in publishing the Fedora flatpak runtime as a target for upstream developers, and I can’t get anyone to agree that there is because of the relatively short support lifetime. That’s a signal that how we are approaching this technology is out of alignment.

I have previously said this would be valuable. I have previously polled game developers about it, which is why I was working on a Fedora base snap several years ago (several were interested in this over an Ubuntu base).

@jspaleta

flatpak at the commandline makes it possible… flatpak as integrated into desktop files (which in the scope of this discussion is a legacy technology relative to flatpak) doesn’t expose flatpaks native capability to allow multiple variants of the same thing to be installed side by side.

As soon as we have a desktop user oriented way to install and access flatpak variants.. we can go crazy and have copr-like federated remotes that don’t conflict.

Then this is where you should start first. Talk to software center developers about this and do this part first.

[jspaleta (Jef Spaleta)]

@ngompa

Then this is where you should start first. Talk to software center developers about this and do this part first.

I disagree.

[ngompa (Neal Gompa)]

The issue here is if you aren’t solving that problem, then your motivation in this Change has nothing to do with it, and I don’t really like it based on the grounds that it implies. If it is about that, then you should be talking to software center developers to expose it properly.

Either way, having alternatives exposed and handled well requires work and advocacy by someone who:

1. Likes Flatpak
2. Wants Flatpak to be successful as a general purpose technology

So far, nobody is stepping up to do that.

[jspaleta (Jef Spaleta)]

@ngompa

The issue here is if you aren’t solving that problem, then your motivation in this Change has nothing to do with it, and I don’t really like it based on the grounds that it implies. If it is about that, then you should be talking to software center developers to expose it properly.

We’re talking about your philosphical concerns.. not my motivations.

[jspaleta (Jef Spaleta)]

disagree. You cut and pasted from my reply to you. Specifically:

flatpak at the commandline makes it possible… flatpak as integrated into desktop files (which in the scope of this discussion is a legacy technology relative to flatpak) doesn’t expose flatpaks native capability to allow multiple variants of the same thing to be installed side by side.

As soon as we have a desktop user oriented way to install and access flatpak variants.. we can go crazy and have copr-like federated remotes that don’t conflict.

which was in response to to you philosophically concerns about hiding the fedora flatpak repo.

[catanzaro (Michael Catanzaro)]

@ngompa

There are also practical workflow problems because any application allowed through the preinstall filter can never be disallowed since doing so breaks their ability to receive updates (unlike DNF, there is no mechanism for auto-switching sources, handling package retirement, removing obsolete software, etc. for Flatpak).

Hm, this is a good point. This is surely fixable, but somebody would have to take interest in working on it.

[kylegospo (Kyle Gospodnetich [bazzite.gg])]

@ngompa

1. Likes Flatpak
2. Wants Flatpak to be successful as a general purpose technology

So far, nobody is stepping up to do that.

That’s because the best thing someone could do for Flatpak as a technology is refuse to step up and maintain these and allow the repo to expire.

[ngompa (Neal Gompa)]

@kylegospo

That’s because the best thing someone could do for Flatpak as a technology is refuse to step up and maintain these and allow the repo to expire.

I’m not talking about repositories, I’m talking about the core Flatpak codebase and features. There are many things that are inconvenient and broken about it right now, which is annoying for a technology that purports that handling multiple remotes as a key differentiator from the main alternative it competes against (Snaps).

[kylegospo (Kyle Gospodnetich [bazzite.gg])]

@ngompa

I’m not talking about repositories, I’m talking about the core Flatpak codebase and features.

Me too. If you want Flatpak to succeed cease all Fedora Flatpak operations, cease shipping them, remove patches from the flatpak package like the forced Fedora flatpak repository via systemd service.

That is an immediate benefit to the entire Fedora userbase and downstream.

This proposal is a good first step to cleaning up this mess.

[ngompa (Neal Gompa)]

@kylegospo

This is an immediate benefit to the entire Fedora userbase and downstream.

Going down that road, I would just say let’s pull out of supporting Flatpak entirely. We should use Snaps instead, because the developer experience is better, there is better active support from its developers, and there’s more buy-in from the industry because Canonical helps them be successful with Snaps.

Because if the key differentiator doesn’t work, it’s not good enough to use on its own.

[kylegospo (Kyle Gospodnetich [bazzite.gg])]

@ngompa

Going down that road, I would just say let’s pull out of supporting Flatpak entirely. We should use Snaps instead, because the developer experience is better, there is better active support from its developers, and there’s more buy-in from the industry because Canonical helps them be successful with Snaps.

Because if the key differentiator doesn’t work, it’s not good enough to use on its own.

This is akin to distros shipping their own themes and breaking downstream applications. The benefit of flatpak is that you can ship your own store, but Fedora has demonstrated that it should not.

If your opinion is that you should drop it, I would be in favor of that because no experience is better than giving users a bad experience. Downstream can always install a clean and unpatched flatpak rpm to undo that change.

[jspaleta (Jef Spaleta)]

@kylegospo

If you want Flatpak to succeed cease all Fedora Flatpak operations, cease shipping them

I disagree. I also think that question is a strategic project direction that is squarely in the perview of Fedora Council.

I don’t want to derail the discussion about this change with a deep dive into strategic direction of Fedora flatpaks to far. I’ve already commented above about possible directions.

I will say this. I expect Fedora flatpaks to continue to exist. Continuing to have a call to stop all operations is not constructive.

I want to ensure it has a scoped mission that makes sense as a benefit for the wider ecosystem in some capacity. I want to make sure its sustainable, that draws on lessons learned historically from EPEL. And if I can figure out a way to do this in partnership with flathub so its existance feels less duplicative. But that’s all just context for possible futures. None of which do I envision shuttering Fedora flatpaks entirely.

[mjg (Michael J Gruber)]

Again, both the proposal and some of the responses fail to acknowledge that the role of Fedora as a distribution is at stake here,the two extremal roles being:

• Fedora as the provider of OS and “apps”, anything 3rd part being “outside”
• Fedora as the provider of the base OS, anything else coming from “somewhere else”

Depending on the point they’re trying to make, people would claim that Fedora is (or should be) in one of these roles. As a matter of fact:

• Fedora is in between already (just look at the default dnf repos)
• takes difficult decisions on principal and legal grounds (compare cisco, pycharm, rpmfusion)

Any attempts at defining a “boundary” between OS and apps have merely lead to ideas of a core with multiple layers or shells around. While that might go well with the idea of “atomic” (huh!), it shows that a black-or-white solution is not that simple to define and build either.

It’s exemplified by the desktop environments: while not strictly requiring “apps”, a DE without a PIM or productivity suite would be considered “dysfunctional” by users. On the other end of the spectrum, merely building some “OS parts” requires “apps” (such as documentation toolchain).

I just wish it’d be easier (or clearer, maybe it’s easy already) to build a Fedora flatpak along with your rpm package even if you don’t use it yourself, similar to how you build rpms for a ton of architectures which you’re not going to use either (as the standard one-arch-packager).

That is, make most of Fedora consumable using different deliverables for updates (rpm, flatpak) just like we do for the releases (iso, vm image, …).

[tqcharm (Mike B.)]

@ngompa

There are also practical workflow problems because any application allowed through the preinstall filter can never be disallowed since doing so breaks their ability to receive updates (unlike DNF, there is no mechanism for auto-switching sources, handling package retirement, removing obsolete software, etc. for Flatpak).

Wouldn’t adding the unfiltered Fedora remote at the end of the list of enabled remotes (i.e. lowest priority) solve this?