F43 Change Proposal: Filter Fedora Flatpaks for Atomic Desktops (self-contained)

Project Discussion Change Proposals
,
1

Filter Fedora Flatpaks for Atomic Desktops

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.

Wiki
Announced

:link: Summary

For the Fedora Atomic Desktops (and only those), we will keep pre-installing a set of Fedora Flatpaks by default but filter the Fedora Flatpak remote to a limited set of applications (the ones pre-installed from the ISO and the runtimes).

:link: Owner

:link: Detailed Description

With this change, we want to make the availability of a Fedora Flatpak an explicit decision for the Fedora Atomic Desktops. Fedora contributors may package any application as Fedora Flatpak, but those Flatpaks will not be made available immediately to Atomic Desktops users. Users that want to have access to all Flatpaks from Fedora can remove the filter.

:link: Why not use Flathub Flatpaks instead?

The most popular derivatives of the Fedora Atomic Desktops (Universal Blue, Bazzite, Bluefin, etc.) do not use Fedora Flatpaks and enable the Flathub ones by default instead.

Moving the Fedora Atomic 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 convenient and valuable.

:link: What are the problems with Fedora’s Flatpaks?

The Fedora Flatpaks have disadvantages that are either structural, or hard to fix:

  • They see little maintenance and traction in the community, and are generally not maintained nor desired by their upstream developers.
  • There is no documentation on how to build, maintain, and update a Fedora Flatpak.
  • There are no procedure to remove or deprecate a Fedora Flatpak.
  • Building a Fedora Flatpak is different from upstream Flatpak builds and Flathub ones.
  • The OCI format used to transport the Fedora Flatpak has many downsides at the moment:

The only advantages that the Fedora Flatpaks have are:

:link: 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) as a starting point.

:link: Feedback

There has been a lot of feedback that Fedora Flatpaks are not what the community and upstream want installed, enabled and offered by default as this notably creates a lot of confusion for users when some features are missing:

The Workstation working group discussed the issue and landed on a decision, which is close to what is proposed in this change: https://pagure.io/fedora-workstation/issue/463#comment-963702

:link: Benefit to Fedora

  • Less confusion for Fedora users of Atomic Desktops
  • 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
  • Less work and pressure for the Flatpak maintainers in Fedora
  • More focus and testing on the Flatpaks installed by default on the Atomic Desktops

:link: Scope

  • Proposal owners: Add a filter to the Fedora Flatpak remote for Atomic Desktops
  • Other developers: N/A
  • Release engineering: N/A
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: Aligns with the goal of making the Fedora Atomic Desktops more attractive to new users

:link: Upgrade/compatibility impact

This change is intended to apply to all Fedora Atomic 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.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: 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 like this previous work:

Once the change is implemented, new installation ISOs for Atomic Desktops will let users tests this more easily.

:link: User Experience

Users installing applications from the GNOME Software and Plasma Discover store will get fully featured Flatpaks by defaults, usually maintained directly by their own developers. We will still install a set of core applications by default on the system as Fedora Flatpaks.

:link: Dependencies

N/A.

:link: Contingency Plan

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

:link: Documentation

We will have to document how to remove the filter for users that want to use all Fedora Flatpaks.

:link: Release Notes

To be written.

Last edited by @amoloney 2025-07-03T19:07:32Z

Last edited by @amoloney 2025-07-03T19:07:32Z

2 Likes
2

How do you feel about the proposal as written?

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

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 :heart: 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.

3

I am not sure I understand the benefit of the proposal.

What is problem this proposal attempts to solve?

The quality of Fedora flatpaks is low so we want to block them by default unless they are bundled with initial image?

What is the resulting user experience here? The user tries to install software and there are no additional applications available?

To be clear, I am not criticizing, I genuinely don’t understand the goal here.

1 Like
4

I am a tad confused by this so please correct me if I’m mistaken or have misunderstood somewhere down the line please do correct me.

Is the future of Fedora desktop not meant to be eventually be all-in for Flatpaks. If so, I would rather see us attempt to improved our flatpak offering unless the end-goal is to depend on a 3rd party application/package store (Flathub) for GUI applications.

1 Like
5

I like this have been using only fedora flatpaks as much as I can on 3 exception on apps I need

-blender still need to use flathub due no cuda on Fedora blender and not updated as regularly

-spotify due license limitations need to use flathub unless ( sysext )

  • signal same as Spotify

-proton mail bridge

These for me only ones I actually use from flathub and I like the way Fedora flatpaks now days work and idea for better control what they have

Not sure did I understand that fedora flatpaks will not be available and flathub is only with Fedora filters?

1 Like
6

I support this change proposal.

As I understand it, the Fedora Flatpak offering will only be a subset of the available Flatpak apps, more specifically the ones that come with the initial installation. If the user keeps the default settings, all the other Flatpaks will come from Flathub, given that the Fedora ones will be filtered out. Users who would still want to access other Fedora packaged Flatpaks, will have such option by either removing the filter, or by adding an unfiltered Fedora remote, if I understand correctly.

Currently, if users want to benefit of the extended multimedia support in such apps (photo, video, browser apps), they need to either layer some RPM-Fusion packages, or go with Flathub apps. The first option requires some more advanced RPM-Ostree knowledge (layer the local RPM-Fusion repos, replace them with the upgradable packages, then layer/install the specific multimedia packages after having done some research). The latter option only requires for the user to install the specific app (e.g. Showtime, Celluloid etc) from Flathub, and the required runtime extensions (e.g. the org.freedesktop.Platform.* ones) will be installed automatically. It’s obvious that the second option is much more user-friendly, and beginner friendly (given that the current issues with mistakenly installing from the wrong remote will not occur anymore).

Some of the Fedora Flatpak drawbacks are also new to me, such as the inability to install an older commit.

Should this proposal pass, the specific Fedora teams’ already limited resources will be better used in other projects.

7

Is Flathub enabled by default on the Fedora Atomic variants though?

Won’t this change lead to a situation where a new user will open the software store after completing the install and literally find nothing there since the only things in the filter will the be the applications already installed?

That just seems like a really off-putting initial experience especially for a less experienced user if that really is what is being proposed here.

8

You need to enable third-party repos on first boot welcome screen to get flathub and rom-fusion repos

1 Like
9

I agree that this change proposal should imply having the Flathub remote enabled by default. Because if it would be opt-in, and the user wouldn’t select the option, the experience would be, as you describe it, less than stellar, to put it mildly.

FWIW, apparently Fedora Legal has no objections against having Flathub enabled by default.

In such a scenario, I imagine the initial setup would inform the users that the Flathub third party repository had been enabled for a great user experience, and that they can opt out, which in turn should remove the filter from the Fedora remote.

10

If there are so many problems with Fedora Flatpaks, then why are we shipping them in the first place? If there are concrete issues that can be resolved (e.g., lack of documentation), are these being tracked somewhere within the Flatpak SIG? Is this an issue of lack of resources? I know RHEL is shipping Flatpaks; is Red Hat not providing resources to make them succeed in Fedora? Is it not having some of the same problems we are?

The Change Proposal lists some very valid advantages of Fedora Flatpaks, namely much stronger guarantees surrounding open source and no pre-built binaries, so it’d be a shame to lose those if the problems with Fedora Flatpaks are solvable.

1 Like
11

Is there a list of explicitly allowed apps somewhere? The question of “which apps will be added to the filter” was never answered in the OP.

12

So, as a consequence of the discussion about filtering Flathub flatpaks to a Fedora-curated subset, you suggest filtering Fedora flatpaks?

Because people complain about “too few apps” and others about “not to Fedora standards”, you suggest restricting the much smaller set of Fedora flatpaks (which are up to Fedora standards - they are rebuilds of distribution rpms) even further? While laying out in your proposal that Fedora flatpaks are bad technology anyways?

Interesting. One may even think the strategy is to prove in one release that Fedora flatpaks take us nowhere and to go full Flathub in the next one.

I think it’s really time to consider what Fedora consists of, both the distribution and the project.

I mean, if a Fedora flatpak “has no place on a user’s” system, then why should the rpm have which the Fedora flatpak derives from? (Yes, we do have too many packages.)

If the benefit is “Stronger focus on what makes Fedora better: upstream contribution and collaboration with other communities” then I’m wondering why not just work upstream, and what’s left of Fedora more than a UBI-like base image?

13

This implies that it’ll start with Flatpaks already installed by default in any of the Fedora Atomic Desktops:

14

I would prefer to not have to worry about Fedora Flatpaks and instead rely on the Flathub version. I think this may be easier for devs involved too.

15

Perhaps this change should only be made for x86 processors. With Flathub, there’s no guarantee that an app will have an ARM build. Meanwhile, Fedora Flatpaks builds for all architectures that Fedora supports.

The same is true of Fedora RPMs. In my experience, most of the actual functionality issues with Fedora Flatpaks are not actually related to Fedora Flatpaks, but the underlying RPMs. Which goes back to the Bottles debate of whether downstreams should package stuff. It seems weird to me to filter Fedora Flatpaks rather than addressing the root cause, either by fixing the broken RPMs or dropping them from the repos.

The codec issue is a bit more tricky. Fedora Flatpaks did somewhat recently (past year) get support for extensions, so theoretically there could be an RPMFusion style flatpak repo to provide Fedora Flatpaks with codec support that Fedora won’t offer itself. Though that would require someone with the motivation to set everything up and host it.

There is a tutorial on Fedora Docs on how to build a Fedora Flatpak
https://docs.fedoraproject.org/en-US/flatpak/tutorial/

To my understanding, flatpak wants to make OCI the default format so that they can use industry standard tooling rather than bespoke to ostree. See: https://youtu.be/3HkYJ7M119I?si=3a2kbJxcDeoJ7yub. If this is the case, wouldn’t it be good for Fedora to continue testing the OCI support? These issues should be fixed if OCI is to become the default, though flatpak’s lack new feature development is a concern.

Or would flatpak moving to OCI natively be a complete restructuring that would replace the current OCI architecture?

1 Like
16

Yes, if you use the Discover on KDE and Software app on Gnome (Silverblue)!

Please observe on the download page, under atomic desktop it still is written:

These editions are supported but not yet a part of the official Fedora editions.

For me it looks like that this request is preparing the atomic spins to get editions and that the user experience is equal on any of them.

And of course totally delivered based on open software.

1 Like
17

@siosm ,
Hello, I think this is a good proposal. It should go ahead IMO. I would like to use something from your proposal, to point out

This, to my way of thinking is not such a bad thing. Though it does go against the general trend of OOTB use and finely polished distro, it does satisfy the reduced clutter state I often desire after a fresh install.

18

This is my understanding of what Fedora Atomic Desktops would look like if this change happens.

First you have the base image.

Then you pull in the Fedora Flatpaks that help to flesh out the new desktop experience but which don’t work as part of the base image.

Then for all other apps you would have Flathub enabled by default, so users would go there for the rest of their needs.

Does that summarize what we’re trying to do here?

If so I am in favor because I agree that we should align on Flathub as being the shared repo all distros can use as much as is reasonable. I think there’s of course still room for rpms and debs, but if the goal of Flatpak is to be a universal package format, then we should move toward emphasizing the universal package store.

19

Is that actually the proposal though? I don’t see that anywhere in the OP unless I am missing it(Which is totally possible).

20

A universal format does not necessitate a “universal” (single) store at all. Indeed, it’s the converse: A universal format enables us to seamlessly use multiple stores.

Even “format” conflates different things: “flatpak the app” can use both “flathub flatpaks” and “fedora flatpaks” because they have the same “outer format” even though they have a different “inner format”. There are those who claim that one is inferior (I cannot tell), but this is independent of where they are stored and who controls the set of flatpaks.