Summary of the discussion about Filter Fedora Flatpaks Atomic Desktops v2 proposal

Project Discussion Change Proposals
, ,
1

I was tasked with summarizing the proposal for Flathub Flatpaks and the surrounding discussion.

I tried to capture the most important arguments and attribute them to sources.

The discussion is long and split over multiple locations, so I apologize in advance if I got something wrong or missed something important. Corrections and clarifications are welcome. I’ll update this doc. Comments in quotes in brackets [like this] are mine.

The proposal

The current proposal is [1], “proposal v2”.

The main part is:

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 verifid floss [verified_floss] subset FlatHub by default.

This is a dense sentence, so let’s discuss some points:

  1. Effectively, most Fedora Flatpaks will be hidden by default, not shown to users who search using flatpak or gnome-software.

  2. Users can restore full Fedora Flatpak visibility by a config change. It’s not clear to me if this will be a simple toggle or a more complicated procedure.

  3. For this change to have good UX, FlatHub must be enabled by default, because otherwise would see an almost empty “app store”. This is against the existing policy (Making sure you're not a bot!) so that policy would need to be adjusted.

    The third-party nature of the repository must be apparent to the
    user when they enable it, as should the non-free status of its
    content, if such. To ensure this, repository files must initially
    include the enabled=0 (or equivalent) setting, and the user must
    explicitly enable third-party repositories to install from them.

  4. This Proposal limits this to image-based desktop outputs. This is certaily a prerogative of the Change Owner to limit it like this. But the Workstation WG is already considering an identical change. Flatpaks are definitely crucial for image-based outputs, but are also used on package-based installs. I also think that we have to assume that whatever decision is made here will set the policy for other outputs. It doesn’t make much sense to allow flathub flatpaks in only some deliverables.

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).

This requirement for pre-installed flatpaks is for legal reasons and to ensure our control over the basic deliverable.

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.
Outputs making use of this filter are expected to provide a disabled and unfiltered remote definition for Fedora Flatpaks

This is item 2. above. The details of how this would be implemented haven’t been specified.

What is changing and why

The main stated motivation for the change is [1]:

  • Less confusion for Fedora users who expect to use Flathub applications

This needs clarification. When using commandline flatpak, the choice is explicit and impossible to miss. KDE Discover shows the source prominently. But even Gnome Software shows the source and allows a choice to be made for each installation. The dropdown that shows this is fairly small, but it is there. So the users already could make the choice, but the default was to use Fedora Flatpaks and the option wasn’t prominently visible.

verified_floss means [11]:

Verification is the process by which Flathub and developers confirm that an app is published by the original developer or an authorized party.

It does not mean that the flatpak is built from source. There is no mechanism or even statistics what percentage of flapaks is just rebundling [3, 14].

As a minor aside, I’m not sure if verified apps can depend on non-verified runtimes.

[3]:

a few applications on Flathub are built on non-Flathub infrastructure, notably Firefox and OBS Studio. It would be better to build everything on Flathub’s infrastructure to reduce risk of infrastructure compromise, but as long as this practice is limited to only a few well-known applications using trusted infrastructure, then the risk is lower and it’s not necessarily a serious problem.

After some discussion, the v2 Proposal was amended to use verified_floss.
But a lot of interesting applications are outside of that subset.
E.g. in [6] a user lists the apps the are using from Flathub (blender, spotify, signal, proton mail bridge) — none are in verified_floss.
I think it is possible that users will still be confused why they cannot find those apps.

[2] handles this explicitly:

Fedora can safely enable the floss subset by default, and replace the “Enable Third-Party Repositories” button with an “Enable Proprietary Software Sources” button that would allow users to switch from the floss subset to the full Flathub if they so choose.

A number of people (me too) have made proposals along those lines:
Jens P> Personally I am more in favor of giving users the option at install time or during initial setup to select Flathub. By that I mean they could chose if they want to just use the default Fedora Flatpaks or select to use Flathub as their preferred remote source (perhaps the actual UI should be to allow changing the priority order of the remotes). This would be more consistent IMO: defaulting to Fedora but allowing users to choose flathub easily if they want that.

John H> At this point, I believe it would be best to simply allow the flathub remote to be enabled by default and indicate to the user clearly what the difference is and how to verify in the desktop environment what version of software they have. There could also be a short tutorial, notification pop-up, etc. just after installation.

Safety and security

In general, flatpaks use limited sandboxing.

E.g. [4]:

Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions, in other words, write access to the user home directory (and more) so all it takes to escape the sandbox is trivial echo download_and_execute_evil >> ~/.bashrc. That’s it.

I looked at the list of most popular flatpaks on flathub (1st page [7]), and all are listed as “unsafe”.

There is also the question of runtimes.

Fedora uses a rolling release of Qt and other runtimes and flatpaks are forced to work with it. This is a double-edged sword. OTOH, this seems to be source of breakage, when the app doesn’t work or work well with the latest upstream. OTOH, on Flathub, “994 out of 3,438 apps are currently using an EOL runtime”. When combined with the lack of sandboxing, this is problematic.

[8] > The “KDE” runtime on Flathub follows QT minor releases. Their wiki states “Once a new Qt minor version is released we will wait one month for marking the previous -2 branch as EOL”. The KDE runtime maintainers are telling users and developers that they have a stable, supported QT runtime for 12 months. This presents the appearance of a KDE-maintained LTS release of QT.
[8] > The problem is, no one is actively maintaining that release. If I report security flaws in QT (and I have), the maintainer will backport a fix from a newer QT minor release. But no one is actively monitoring QT in that runtime for CVEs.
[8] > Today, one of the most visible reasons that it looks like Flathub decouples applications from the base OS lifecycle better than Fedora does is that the KDE runtime is shipping an insecure, unmaintained QT release, while Fedora ships QT as a rolling release, because that’s the only secure way to ship QT.

Nevertheless, I think this is a good counterargument:
JPL> The fundamental difference is who is choosing. When upstreams choose to publish a flatpak they are making a statement as to which runtime they support. The fedora flatpaks as constructed right now are not upstream choices.

In [2], proposals how to improve this on Flathub have been made, in particular changing the Flathub policies. But no such changes have been made.

[2] is also a year old at this point, but it didn’t embrace flathub without reservation:

Flathub has a few serious problems, and needs to make some policy changes before Fedora enables it by default.
Flathub is, frankly, not safe enough to be enabled by default in Fedora Workstation today.

Lack of source and build system provenance […] This is a serious problem, and it would be unacceptable for Fedora to embrace Flathub before it is fixed.
Lack of separation between FOSS, legally encumbered, and proprietary software: this is not a real problem. Flathub already has a floss subset […] Desktop users invariably wish to install encumbered software;
Lack of systemic upgrading of applications to the latest runtime […] This is a serious problem, and it would be unacceptable for Fedora to embrace Flathub before it is fixed.
Lack of coordination of changes to non-runtime dependencies: this is a difference from Fedora, but it’s not necessarily a problem.
Lack of systemic community engagement: it’s silly to claim that Flathub has no community. Unresponsive Flathub maintainers are a real problem, but Fedora has an unresponsive maintainer problem too, so this can hardly count as a point against Flathub.

The proposal in [2]:

  • Open source software must be built from source on trusted infrastructure.
  • Applications must not depend on end-of-life runtimes.
  • Applications must use flatpak-external-data-checker to monitor bundled dependencies wherever possible.
  • Sandbox holes must be phased out, except where this is fundamentally technically infeasible.

Little progress has been made on 1, 2, and 4, and 3 has seen limited adoption.

Legal support

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.

Not much to add here. We are allowed to do this.

Architecture support

Concerns have been raised that flathub does not provide flatpaks for all architectures.
Going one by one:

  • Arm32: we have dropped support for arm32 in Fedora, so this is not a concern.

  • Aarch64: it seems flathub has fairly good support:

    Jaiden R> We don’t ship Fedora Flatpaks downstream in Ultramarine,
    but we don’t have the same needs as Fedora. We support x86 and
    aarch, and Flathub offers the majority of their packages for aarch.

  • PowerPC: no support and no plan for it. PowerPC is our primary architecture and we have desktop deliverables (KDE) and they see use.

  • Risc-V: no support, no clear plan. Even if Fedora/RH helps flathub with infra, I think it’s unlikely that the majority of apps wiill be built for Risc-V quickly.

One suggestion made was:

Whenever a Flathub app is not available for ARM, we should allowlist a Fedora Flatpak for that app if one exists, so the Fedora version takes precedence over the Flathub version (preferably on all architectures).

This would make the proposal moot, because PowerPC is a primary arch.
Also “based on updated CLE discussion […], RISC-V primary arch enablement is currently anticipated to be 15 to 18 months out”.
So we have to assume that we’ll need to use the Fedora Flatpaks and allow different sources on different architectures.

Also, [Michael C] “RISC-V users will still have access to RPMs. They just might have a hard time if trying to use an immutable system”. I think this is a valid point. Early RISC-V boards are going to be underresourced, so using package-based installations and rpms makes sense. I think image-based RISC-V installations are not an immediate concern.

Upgrades and retirement

This is a complicated topic and I’m sure I missed some parts of the discussion.

In short, if a remote provided a flatpak and stops doing that, the user is never moved to another source and keeps the obsolete version.

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).

There was a discussion whether the preinstall filter would be expected to change often. It turns out that Gnome default apps change regularly (~1–2 per release):

Mike B> But then again, what are the chances that an app appearing in the filtered remote, as per this change proposal, would be retired a few releases later, given that these Flatpaks would mainly be GNOME core apps?
Neal> pretty high (F44 Change Proposal: Filter Fedora Flatpaks Atomic Desktops v2 [SelfContained] - #39 by ngompa)
Neal> GNOME Console would have to remain in our filter list permanently.

Also, the Proposal states

Users that are using Fedora Flatpaks may have to enable the full fedora flatpak remote to keep receiving updates.

This raises a risk: without the explicit action, users will be stranded with obsolete versions of apps outside the filtered subset. I think the Proposal needs to address this.

Fedora flatpaks and attracting contributors

Fedora Flatpaks continue to fail to attract interested developers. The quality is lower than Flathub.

This is hard to quantify. Actually often the reason is that the underlying rpm is missing features. Obviously, Fedora has strict rules about codecs and licensing. So the shortcoming might not have to do anything with the flatpak part. But users don’t care about this, they want the app that works.

The Proposal doesn’t mention this, but I think this is one of the crucial reasons why users like flathub. It offers more software with less restrictions. This is fine, but I think we should be open about this.

Gordon Messmer in [5] raises the issue that to become a flatpaker, once needs to be in @packager. But [15] only lists “new package”, “comaintainer”, “adopt orphaned” as possibilities. So we ask potential maintainers to learn and to commit to something that is unrelated to flatpaks. We could attract more Fedora flatpak contributors is we relaxed this policy.

OTOH, flatpak fixes often require .spec changes, so flatpakers would also need to know rpms and build them. So some nuance is needed here, but we should consider relaxing the policy.

MJG> 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).

More philosophical concerns

A number of comments expressed dissatisfaction with Fedora hiding its own outputs.
(“Fedora hiding its own outputs from users is a pretty dark signal”).
It’s not entirely clear if it would be possible to show Fedora Flatpaks but with lower priority.
[2] discussed a number of arrangements, so “filtered fedora > flathub floss_verified > unfiltered fedora” could maybe be an option. Maybe this should be discussed more as an alternative to the current form of the Proposal.

[8] > Furthermore, while Flathub enables upstreams to build and distribute their software in a way that all may easily consume it, as far as Free and Open Source Software is concerned, that does not preclude others from doing the same. In other words, just because a FOSS upstream has their preferred packaging does not negate or counteract the rights of downstreams to distribute their own packages of the same software in line with the license which the upstreams have themselves freely chosen.
[8] > Unfortunately, this has been forgotten or ignored by certain upstreams, which, now being empowered to build and ship their projects themselves, suddenly believe that nobody else should distribute their software, and have even become outright hostile to downstreams in general.

[2] > Feedback from Fedora’s user base has been clear: among users who like Flatpaks, Flathub is extremely popular. When installing a Flatpak application, users generally expect it to come from Flathub. In contrast, many users of Fedora Flatpaks do not install them intentionally, but rather by accident, only because they are the preferred software source in GNOME Software. Users are often frustrated to discover that Fedora Flatpaks are not supported by upstream software developers and have a different set of bugs than upstream Flatpaks do. It is also common for users and even Fedora developers to entirely remove the Fedora Flatpak application source.

JPL> I could argue that an expansive reading of the existing packaging policy concerning justification of downstream patches which is supported by the principle of upstream first would imply that anytime we are not preferring the verified upstream flatpak that should require an exceptional justification process.

I think this is completely bogus. In general, Fedora’s raison d’etre is to take upstream software and package it. Both licensing and standard practice allow this. I agree with the sentinment expressed in [8] above. We might want to start using 3rd party packaging, but it is certainly our right to use our own.

JPL> I do not expect everyone to agree with regard to the benefits. This is why the proposal is explictly opt-in.. not a requirement for all outputs.

I think this is not a good argument. Because the choice is made at some SIG level, but of course individual users have their preferences too, and in this area those preferences don’t need to be aligned with the SIG choice at all. User choice is an important consideration too.

JPL> flatpak as a technology is meant to be federated, and how we are approaching that isn’t really working for that. If it were working we wouldn’t need a filter to resolve the conflict inherent in what should be additive non-interfering application choice.

Arguably the proposal with a filter isn’t federation either. In fact, it could that we’re going from a more federated system to a centralized system with a single gatekeeper, akin to properietary app stores. Federation is clearly hard, but improvements in the UI could also make it better.

Handling of the proposal and comments on the proposal itself

Jef raise the problem that FESCo hasn’t voted on the v2 proposal quickly. This is a valid point — contributors should be able to expect a resolution within a reasonable time frame, and this hasn’t happened here. The discussion has mostly died down at least two weeks ago.

Here are the reasons which I think contributed to this:

  • the topic is surprisingly complex and we’re all a bit tired: the people who want to use flathub, the people who prefer our flatpaks, FESCo members, etc.
  • we had a FOSDEM and F44 Beta in the meantime, so people were busy
  • the v2 proposal avoids criticizing Fedora flatpaks, but of course since we are switching from our thing to something external, the question “why, what is wrong with our thing” is only natural. Various people have raised this in the discussion. Actually, v1 of the proposal was open in this regard: it enumerates a bunch of shortcomings of our flatpaks.
  • subsequently, the motivations that are listed are weak. The reader is left to guess what the actual motivations are. In the discussion thread, this was raised multiple times. I made an attempt to clarify the motiviations in this text.
  • there are some important choices and tradeoffs in what is enabled in the filter. I would expect the proposal to enumerate the options and provide rationale why verified_floss is the best choice. This is missing.
  • If we enable verified_floss by default, a lot of apps will be excluded. Do we change the “enable 3rd party repositories” toggle to “enable proprietary and non-verified flatpaks”? This is also missing from the proposal.

Proposal> 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.

I don’t understand this.

Proposal> Contingency deadline: Beta/Final freeze

The idea here is to make a choice :wink:

JPL> So the opt-in filter is a compromise that we can implement right now, while we figure out the full technical solution and restructure our flatpak offerings so that they are not in direct conflict with upstream efforts.
JPL> This is no getting around that this proposal is a compromise. A compromise that is implementable within the existing constraints that reduce the heat and friction between different points of view inside the existing Fedora contributor base about the interplay between upstream first policy and the mandate to provide an integrated solution as part of Fedora.

This is from the discussion. I think it’d be helpful if this was part of the Proposal. Also, if this is a compromise for current technology, what is the long-term plan?

[1] https://fedoraproject.org/wiki/Changes/FilterFedoraFlatpaksAtomicDesktopsv2
[2] https://blogs.gnome.org/mcatanzaro/2025/07/21/fedora-must-carefully-embrace-flathub/
[3] https://hackmd.io/@travier/rJCQMdZBee “List of Flatpaks on Flathub apps not built from source”
[4] https://flatkill.org/2020/
[5] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PMUCDS26MOHHIG3VEGTSRMQYWGMDWK52/ “Recruiting flatpak maintainers”
[6] https://discussion.fedoraproject.org/t/f43-change-proposal-filter-fedora-flatpaks-for-atomic-desktops-self-contained/157262/5
[7] https://flathub.org/en/apps/collection/popular/1
[8] https://yselkowitz.github.io/blog/2025/02/25/the-case-for-fedora-flatpaks.html
[9] https://docs.fedoraproject.org/en-US/flatpak/tutorial/ (not referenced in the text, just interesting)
[10] https://src.fedoraproject.org/flatpaks/blender/blob/stable/f/container.yaml (not referenced)
[11] https://docs.flathub.org/docs/for-app-authors/verification
[12] https://docs.flathub.org/docs/category/for-app-authors (not referenced)
[13] https://github.com/skyler544/minus-one/blob/main/build_files/ensure-flathub.sh (not referenced)
[14] https://pagure.io/fedora-workstation/issue/492
[15] https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#requesting_sponsorship

Last edited by @zbyszek 2026-03-10T13:48:49Z

Last edited by @zbyszek 2026-03-10T13:48:49Z

1 Like
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 have to address this one…
because we are talking about pre-installed things to meet legal obligations its not just a matter of switching out remotes post-install.

We have to have a remote defined that services the updates to the pre-installed applications.
To ignore the desire for pre-installed flatpak application is to ignore the complexity that mandates the use of a filtered remote enabled by default.

4

I appreciate your inclusion of key points from my blog post in your summary.

Runtimes do not receive verified or non-verified status. There are only a few runtimes (freedesktop.org, GNOME, KDE) and they are effectively well-known, so it’s just not necessary.

I suspect the proposal owners would not be too upset if the change were to be approved on the condition that we use a different subset. The options today are floss and verified_floss, but I understand Flathub is open to adding new subsets, provided Fedora does any required implementation work. It’s safe to assume that somebody would be willing to volunteer to make this happen. My preference would be a hypothetical floss_from_source subset. verified_floss_from_source is also possible.

My $0.02:

  • Built from source should be a blocker, which we should address via a new subset.
  • EOL runtimes should be a blocker, but there are various possible solutions to this. Ideally Flathub policy would become stricter. We can also possibly address this via scarier warnings in GNOME Software and Plasma Discover.
  • I wouldn’t block on the other two issues. The Flathub community is already interested in expanding use of flatpak-external-data-checker. Then sandbox holes in Flathub apps are simply not a problem relative to Fedora RPMs or Fedora Flatpaks.

We have recent data for Workstation and it looks like roughly 5-10 PowerPC users total, so I think we should only worry about x86_64 and aarch64 today, and possibly RISC-V in the future. My main concern here is specifically that some Flathub applications build only for x86_64 and not also for aarch64. A Flathub app missing a standard architecture supported by Flathub (currently that’s x86_64 and aarch64) should be considered a good reason to give a Fedora Flatpak higher precedence than a Flathub Flatpak.

Fair point.

1 Like
5

It is best said, that there will have to be public discussion to negotiate what is achievable in a cross-project fashion in the spirit of an upstream first approach to iterating towards a mutually beneficial future that more optimally empowers end-users to take full advantage of the power and freedom of open source software.

I think trying to mandate quality requirements to upstream projects is not in the spirit of Fedora’s upstream first guidance principle. We should be approaching the discussion with upstreams with a goal towards iterating towards improving aspects that we think are important.

1 Like
6

Gave the post an honest read and as a regular user who browses the web and games every now and then, this feels like helicopter parenting and security obsession. As long as I can activate Flathub repo and remove Fedora repo (as I’ve always done and always will) all is good for me.

One thing I agree with is apps using EOL runtimes. Last time I used OBS a month ago it was using EOL runtime, giving me warnings.

Now, I am a simple user with simple needs, so I might and probably do fail to see the big picture here, but I don’t think with flatpak it will be possible to cover all bases from security, clarity and what-not so maybe loosen the grip and trust the end user a bit? I am wholly against this proposal.

That’s my basic two-cents and as always, I trust the smarter folks with whatever decision is taken :slight_smile:

7

I think there is a misunderstanding of Fedora’s Upstream First principle in the context of this proposal. The principle is focused on working with upstreams as part of downstream packaging and integration process and contributing any changes, fixes, or improvements Fedora packagers make back upstream whenever possible. It is not about throwing away downstream packaging entirely and it is also not about shipping software that doesn’t meet Fedora’s standards and Packaging Guidelines just because that’s what upstream does. Packages that don’t follow our Packaging Guidelines and Licensing Guidelines are not approved for inclusion or get removed. Packages that don’t get fixed for the new language stacks that we package in Fedora (as part of our Upstream First–inspired efforts to integrate the latest language toolchains versions early and contribute fixes and bug fixes upstream!) also get retired. I don’t think Flathub or any other source that’s enabled by default should get special status here.

3 Likes
8

I believe that the upstream first principle that Fedora aspires to sometimes requires tradeoffs that create situations that degrade quality for periods of time as we work with upstreams to make important transitions.

This is likely one of those transitions.

This proposal is explicitly opt-in so that the Fedora outputs that want to take a more susbstantial upstream first approach can do so.

This is nothing like the transition from Gnome 2 to 3.. which was very painful because as a project we took the jump in one swoop across the entire repository at the time..impacting the “default” user experience.

This proposal delibrately makes this opt-in for the more curated user experiences that want to take an upstream first approach to flatpak as a platform.

1 Like
9

I believe I have a different interpretation of the principle.

I believe that flatpak is materially different than rpms because its intended to be a cross distribution platform. I think a more expansive reading of that principle must be done to take into account the nature of flatpak a as a platform.

I think the filter list in this proposal is an expression of justifiable exception to the upstream first principle in the scope of what flatpak as a cross-distirbution platform is meant to be.

10

Point of information…
When an rpm is retired… and a user upgrades.. what the expected procedure for them that doesn’t require explict action by the user to remediate?

11

Or more imporantly.. do we have any process right now to handle what happens if for some reason a Fedora flatpak is retired?

My point is.. flatpak as a platform has a lot of rough edges already in terms of handling transitions. Im not sure expecting this proposal to fix those rough edges in order to be adopted is a reasonable requirement.

12

We have a self-destructing RPM called fedora-obsolete-packages that handles this on Fedora upgrades. DNF will remove obsolete packages as part of update/upgrade transactions.

1 Like
13

@gotmax23’s interpretation is the accepted one. There is nothing about “Upstream First” that requires us to e.g. not package software for Fedora (in any form) just because upstream thinks they should be the only ones to do so (contrary to the license that they have themselves chosen).

5 Likes
14

Please consider not using the term “upstream first” then. @gotmax23 linked our official documentation that describes the well-established meaning (“changes and improvements to open source software should, whenever possible, be shared back with the upstream projects”). It doesn’t really matter if your meaning is better — it might very well be — but if everybody else understands the term in a different way, it is hard to communicate.

Lots to untangle here… First, “upstream first” is about pushing improvements that we do downstream into upstream projects, so that they can be shared by other users and downstreams. In other words, it is about improving the quality of the upstream project. It does not mean we abandon downstream packaging and improvements. Second, whether we use some third party packages is not even about upstream. Flathub is a downstream like us. Third, as also discussed during the meeting, while we cannot dictate to upstreams, we certainly can ask for improvements. We do that all the time. Every issue opened is such an ask.

Let’s for example consider a hypothetical switch to clang as the default compiler. We would evaluate if it has less bugs than gcc, maybe ask for improvements in compilation speed and to some specific warnings, and upstream could take that up or not. By making that choice based on technical and other merits, we are not dictating anything to either of the upstream projects.

flatpak as a platform has a lot of rough edges already in terms of handling transitions. Im not sure expecting this proposal to fix those rough edges in order to be adopted is a reasonable requirement.

It is reasonable. The proposal is about making a huge transition, so naturally the question of how upgrades are handled during the transition comes up. This is true for many proposals. In fact, often the handling of the transition requires the most work, and often there are unexpected troubles.

It’s possible that fixing those rough edges is too hard. But as far as possible, a reasonable proposal should try to address such problems.

I believe that the upstream first principle that Fedora aspires to sometimes requires tradeoffs that create situations that degrade quality for periods of time as we work with upstreams to make important transitions.

Sometimes we accept temporary degradations, but not happily, and certainly much less than we used to. In particular, Rawhide used to be a dumping ground where people would chuck half-baked releases and break things. We now have gating and Rawhide is intended to be fully functional at all times. The same could be said for upgrades: the gold standard is that user presses a button, comes back after a coffee, and they are on the new release. Everything that requires manual twiddling or creates a visible regression in behaviour is unwanted.

Also, we have gotten much better at doing incremental smooth improvements. We want to support users who only interact with the graphical layer and are not computer enthusiasts, but that means that upgrades should happen automatically and smoothly.

And in doing changes, we have the Change Process to map out the whole journey so that we know what work needs to happen ahead of time. Not all the details, but the rough roadmap, where we start, what steps needs to be taken, and what is the desired end goal. We have learned the hard way that attempting a transition conditional on work being done in other projects is very risky.

2 Likes
15

Quotes

This is something that especially important to point out.

Most of the issue’s I’ve experienced with Fedora Flatpaks were not issues with the flatpak itself, but with the underlying RPM

If Fedora wants things to “just work”, then it should fix the underlying issue (the broken RPM) or simply stop packaging the software. It does not make sense to “compromise” by keeping the broken RPM but hiding the flatpak that consumed the broken RPM,

Again, this same point is also entirely applicable to RPMs. Why are we talking about flatpak here?

The fact it is a portable format matters little in practicality. The end result is the same: the user installs a package, it appears in their app list, they click on it, and it either works or doesn’t. It being an rpm or flatpak does not change the perception of the issues they experience or make it suddenly more or less actionable to upstreams they report issues to.

My Question

If it’s agreed that Fedora should hide Fedora Flatpaks because they are not supported by upstream, then why is Fedora packaging any software that has offical packages?

The line of thinking from these points suggests that Fedora should not package most things. It should only package the minimum to provide an OS from where a user then installs packages from official sources like Verified Flathub, Verified Snapcraft, offical Appimages, tar.gzs, etc.

Not unlike the direction Gnome OS, KDE LInux, and Flathub are pushing.

My view

Not saying the above is my view, I personally use Fedora Flatpaks where they work well (pretty much anything that does not need to use restricted codecs). I also use plenty of stuff from Flathub for anything either not in Fedora Flatpaks or where Fedora Flatpaks do not work well (as mentioend, restricted codecs).

I don’t think Fedora should hide its own packages if those packages exist. Either commit to promoting the packages you create or package the bare minimum to have an OS that consumes official packages from upstreams (and perhaps package anything that does not have official upstream packages).

1 Like
16

Hiding is the exact wrong concept. This is about deconflicting the choice between peer flatpak remotes that users could choose from, so that its possible to pre-install only what is absolutely necessarily and make it okay to choose which remotes are enabled beyond that.

We have a legal determination that its okay to enable Flathub by default.. this is material to the discussion because we do not have legal opinion that allows us to enable any 3rd party rpm remotes at present afaik. That is an important distinction, there is a difference between flatpaks and rpms. That difference is so significant that it impacts the legal restrictions that this project must abide by. Having a legal opinion saying its okay for the project to enable a 3rd party anything by default is significant. That makes flathub flatpaks more like the linux foundation’s linux vendor firmware service.. which fedora relies on for hardware enablement.

The LFVS is probably the closest analogy with our relationship with Flathub. A a project we made peace with relying on LFVS as a way to solve a problem we aren’t equipped to solve as a single distribution.

But the related question is why rpms? It comes down to integration and the granularity of components compromising the integration.

Fedora as an rpm distribution is an integrated collection of software intended to be used together. There’s no clear distinction between the base OS and the applications in how the Fedora rpm distribution is constructed… no distinct API boundaries… just a pile of dependencies between packages…sometimes circular. But there is value in the granularity.

The granulity is valuable, but it comes at a cost. This is why Fedora has the EPEL subproject because you can’t just use Fedora rpms on CentOS and RHEL, you have to rebuild fedora src packages so they “integrate” with those OSes.

Flatpak is materially different, in that as a technology it is meant to be a platform that allows applications to work across different operating systems. it doesn’t try to provide the base OS, it assumes its there, and it assumes that the base OS provides a certain set of APIs. Flatpaks don’t “integrate” with the base OS, they “layer over” it.

As long as other OSes provide what Flatpak as a platform requires, its possible to take the Fedora Flatpak remote and use it on those other OSes. So in my mind at least it should be considered in the same vein as EPEL in that its a subproject it has ecosystem-wide scope and usability. Flatpaks are not “integrated” they “layer on top” and that has value, but its different value than the granular integration that rpm packaging provides to users.

In many ways flatpak and rpms are different points of a continuum of how binary packaging can be done when you applications that depend on the same dynamically linked libraries and you want to mimimize the number of copies of those libraries installed on the system.

Here is the reality. If Fedora outputs want to have applications pre-installed based on flatpak instead of rpms Fedora must provide those flatpaks because of legal requirements. Anything beyond that is a choice to rely on flathub and remote subsets are enabled by default because flathub be being a ecosystem-wide application store that “layers over” instead of “integrating with” we are able to enable it.

The legal opinion that allows us to enable Flathub by default is a rare opportunity to engage directly with upstreams in a way that we are rarely legally allowed to do. It benefits all of us if we can work with Flathub so that they can be a trusted partner for the entire ecosystem in the same way LFVS is. We’ve got work to do on that. I don’t think this is a linear process. I think there is a need to open up a space where Fedora outputs that want to be in partnership with Flathub to be on a journey to get it to LFVS-like partner status, doing things in a sufficiently secure way so we can more fully integrate it.

I’m sensitive to the concerns that there are deficiencies in the FlatHub process and its not quite to the level of trustability that LVFS is. But we need to take a step forward on that path. Allowing outputs to opt-in is one first step that lets us hopefuly take more steps in a more collaborative stance.

2 Likes
17

We can, provided they comply with the third-party repository policy, in particular:

  • Just as with any software hosted by Fedora, third party repositories must not contain material that poses an undue legal risk for the Fedora Project or its sponsors. This risk includes, but is not limited to, software with known patent issues, copyright issues, or software tailored for conducting illegal activities. Fedora working groups should evaluate if a proposed addition or provider poses a significant risk, and if in doubt, confer with Fedora Legal for advice.

And:

  • Working groups and SIGs should maintain oversight over the software that is made available through third-party repositories, to prevent unvetted software being made available to Fedora users. As part of this, third-party repositories should allow easy auditing by Fedora Legal. This requirement implies that third-party repositories should limit themselves to a small number of packages, or that measures should be put in place to define which packages are made available from a particular repository by default.
1 Like
18

I should clarify… permission without an assessment of “undue legal risk” clause associated with patents and other things… because again rpm repositories are materially different in nature usually because they “integrate” with a base OS . there is no general expectation that rpm binaries will work equally well across the linux based OS landscape. Sure you can shove a static binary into an rpm and find a way to install and run that binary on debian(where there is a will there is a way) but its not the expected nor intended use. I’ve personally yet to see an rpm repository that is a collection of many things that claims to have ecosystem wide utility.

And its clear that the policy is speaking about rpm repositories, and hasn’t really been updated to anticipate flatpak remotes… which have ecosystem wide utility and are not integrated extensions of a particular base OS.

All of that is to say the 3rd party ‘rpm’ repository policy is basically an upgraded version of what the fedora.us had to agree to in order to morph into Fedora Extras back at the dawn of the project where Fedora Core was the base OS built inside of a Red Hat controlled build system and defined what was possible to include in the installable outputs ( iso images). So nothing has really changed in the 23 or so years or so, that policy looks a lot like what I remember fedora.us had to adept to as part of the transition, which resulted in the formation of livna, if memory serves, to catch some of the things that were no legally appropriate.

Flathub(and really any flatpak remote that were to be spun up) and LVFS are materially different exactly because they intend to have ecosystem utility.

I keep thinking about what a Fedora Project would have looked like if flatpak had been a technology available in 2002 and flathub had existed side by side with fedora.us as external community efforts avallabile to RHL users… in that critical period. My opinion is, based on my lived experience as a minor contributor to fedora.us, is flathub would have just been enabled from day 1 in Fedora Core 1… because there wouldn’t have been a legal reason not to. That’s where I’m coming from. Fedora.us had to adapt itself to meet legal requirements in order to be enabled because the 3rd party _rpm_repository policy must encode assessment of legal risk of “integrations”… something that flatpak remotes don’t have to concern themselves with as they are not “integrations” and are expected to have utility broadly across the OS landscape.

19

In the meeting yesterday we agreed to write what changes we’d like to write in the proposal. This is hard, because the goal is not criticize the existing one, or to write my own proposal, but to help establish boundaries and expectations for a good proposal. The discussion yesterday about accepting temporary degradations in quality helped me frame this.

Problem statement: Fedora provides its own flatpak repo that overlaps with Flathub. Many users would prefer to use the Flathub flatpaks, but using the graphical environment they often end up installing the “wrong” version because Fedora is configured as the default remote.

Goal: Avoid the situation where users install a version that doesn’t work for them. Provide enough information for users to make a choice, don’t force the choice on them.

Assumptions:

  • Users want to have access to as many kind of flatpaks as possible, incl. stuff with codecs and other patent-encumbered stuff.
  • Some users care about a FOSS license, others do not. Similarly for other attributes like “built-from-source”, “verified”, “safe”.
  • I assume that users who have preferences might compromise in specific cases, e.g. if the flatpak is particularly important to them. For example, if I need org.telegram.desktop, I’m going to run the version that is available, even if it is not “verified”. OTOH, I might not download a game if it is not “verified”.
  • As a project, we’d like to make users aware when they a) install software that is not provided by Fedora, b) install software that is not FOSS, c) install software that has packaging shortcomings, i.e. old runtimes, is not built from source, is “unverified”. At the same time, we’d like to make it easy & convenient to gain access to such software. Ideally, through an obvious toggle.
  • As a project, we’d like to maintainer “federability” of flatpak, i.e. allow access to both popular Flathub, but also to our own remote.
  • If we change the defaults or remotes, existing installations should continue to be upgraded and should not require manual intervention.
  • User preferences should be maintained, so if a user installs from one remote, they shouldn’t be switched to a different one on upgrades, unless the old remote stops providing something.
  • We care about multiple architectures, at least amd64, arm64, and risc-v, and we want to provide flatpaks for all of them. (Possibly not now, but later.)
  • Flatpaks with EOL runtimes and other shortcomings are a real security issue.

Considering all this, I think the existing proposal might make various groups unhappy:

  • if we only offer verified_floss, a bunch of important flatpaks would be excluded, e.g. chrome, spotify, steam, vlc.
  • if we cut this even further to “built from source”, we make the problem worse.
  • OTOH, Fedora developers and security-conscious users might want to install the Fedora flatpaks without jumping through hoops.
  • In general, strict filtering is not great. A soft search result which says “there are more options, but your current policy excludes them. Click here to see more.” might be much more liked by users.

Dunno, after writing all this out, I feel more and more that this is a social and UI problem, not something to be solved at the technical level. Would it be an option to get some UI and UX designers to chime in, possibly suggesting some solutions how to make users happy?

1 Like
20

Let me digest your perspective as a FESCO member, as well as other FESCO members and take it back the the GNOME AdBoard and see if there is enough consensus to organize a hackfest that puts the correct people in the room to address some technical issues.

At the last AdBoard meeting I put forward my perspective as to some underlying technical issues in flatpak and possibly the freedesktop specifications that I felt could be solved below the UI to help deconflict. I continue to push back that the problem is fundementally in the UI.. but deeper in how flatpak and freedesktop interact to make it difficult to have variants of the same application installed (including when you have rpm and flatpak installed side by side on the same system)

I think focusing on the UI store interface missing something fundamental. The UI is important, but at the same time the UI shouldn’t actually be where this is solved in my opinion… because the UI is suppose to be opinionated..its its job.

With that said, I’m not sure the problem statement as you describe it is worded broadly enough to pull in interested parties outside of Fedora so I need to think about interpretting your problem statement as a piece of the larger statement that unlocked discussion that ended with a hackfest proposal in the AdBoard meeting in conjunction with FOSDEM