Filter Fedora Flatpaks for Atomic Desktops Version 2
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 verifid floss subset by default. If output maintainers choose to enable Flathub verified floss 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: Jef Spaleta
- Email: jspaleta@redhat.com
Current status
- Targeted release: Fedora Linux 44
- Last updated: 2026-03-25
- Announced
- Discussion thread
- FESCo issue: #3549
- Tracker bug: #2451366
- Release notes tracker: #324
Detailed Description
With this change, we want to make use of Flathub verified floss 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 the Flathub verified floss subset enabled by default, unless they are preinstalled applications. Users that want to have access to all Flatpaks from Fedora can remove the filter or enable an additional remote definition that the filter doesn't apply to. Outputs making use of this filter are expected to provide a disabled and unfiltered remote definition for Fedora Flatpaks.
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 verified floss 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. the filter will initially start with pre-installed Flatpaks (and the runtimes) in SilverBlue, but can increase to include additional flatpaks to meet the requirements of additional image based desktops that want to enable Flathub verified floss by default.
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 verified floss 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 verified floss 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 verified floss 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 verified floss 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 verified floss 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:
Flathub has already been determined to be allowed to be enabled by default, this Change establishes a mechanism to actually do that.
This impacts FESCO's existing discretionary policy concerning the enablement of 3rd party repositories.
If FESCO is not prepared to make it explicit that floss verified flathub is allowed to be enabled, there is a fallback position where Fesco could decide to allow the filtering Fedora Flatpaks while keeping the choice to enable Flathub by default as a discretionary case-by-case policy as a compromise that allows the filter implementation to exist. This fallback decision would result in outputs where Fedora users would be asked to choose to enable the flatpak remote(s) they want to rely on for additional software treating the full Fedora and Flathub as peer remotes.
- 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 enable the full fedora flatpak remote to keep receiving updates.
Early Testing (Optional)
Do you require 'QA Blueprint' support? N
How To Test
Disable Fedora Flatpak remote, enable filtered Fedora Flatpak remote, enable Flathub remote restricted to verified floss subset. 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.
