fesco

#3573 Updates to third-party repository policy
Closed: Accepted by catanzaro. Opened by catanzaro.

Closed: Accepted
Reopen Issue

Hi FESCo,

Since Fedora 38 - Unfiltered Flathub change proposal, we have not been in compliance with the Third-party repository policy. I propose the following changes to the policy to reflect the approved F38 change proposal:

  • Rename the section "Third-party repository distribution" to "Third-party RPM repository distribution" and change the first sentence from "Third-party repositories should be distributed in descriptively named rpm packages" to "Third-party RPM repositories should be distributed in descriptively named RPM packages," to clarify that none of this section applies to Flatpak repos.
  • Under "Key requirements for third-party repositories," change the text from "Additionally, repositories included in an edition or spin’s third-party repository list must conform to the following requirements:" to "Additionally, repositories included in an edition or spin’s third-party repository list must conform to the following requirements unless otherwise approved by Fedora Legal." After the bulleted list, add a sentence: "Currently, Flathub is the only third-party repository with an approved exception to this policy." It will likely be very rare for repos to receive this exception, so I think it's OK to edit the text of the policy when it happens.

I think the changes above should be uncontroversial since the goal there is to document the status quo as of Fedora 38, not change the status quo.

Now it's time for the controversial part: if the new Filter Fedora Flatpaks change proposal is approved by FESCo, then we would likely want to additionally change the section "Duplicates and replacements" since the current wording pretty strongly implies that Flathub should not take precedence over Fedora Flatpaks. We could just add a new sentence to the end: "Currently Flathub is an approved exception to this policy."

But why shouldn't it apply to Flatpak repositories? What if someone wants to ship the 1Password Flatpak remote as an option? Or the NVIDIA GeForce Now! one, once they have it? I think it actually makes sense to encapsulate Flatpak in that policy, because there are ISV Flatpak repositories, and users may want them available as third party sources in Fedora.

The policy as a whole covers both RPMs and Flatpaks, but some of the language in the "Third-party repository distribution" section needs fixed because it's clearly specific to RPMs but lacks language to clarify this. For example:

Repositories can be configured with either enabled_metadata=0 or enabled_metadata=1 (or equivalent), at the discretion of the relevant working group or SIG.

And:

repository files must initially include the enabled=0 (or equivalent) setting

(Flatpak has no equivalent for enabled=0.)

Most importantly, the rules in this section require repo definitions to be distributed via RPM, but Flathub is not enabled via a file packaged in an RPM, but rather by running flatpak remote-add (reference). So it seems clear that the guidelines in this section are clearly intended to apply to RPMs.

In contrast, the section "Third-party software requirements" section lays out separate requirements for RPMs vs. other packaging formats, so it's only the first part of the policy that seems confused.
Edited by catanzaro

We've sort of made an equivalent mechanism with fedora-third-party, though, so perhaps it makes more sense to explicitly outline that.

I think we should go in exactly the opposite direction to the proposal and adjust/extend/clarify the policy for flatpaks. It was actually intended to cover non-rpm sources too, which is why it is worded as it is, but it could certainly be reworded to apply better. The fact that flatpak has no equivalent for enabled=0 is a problem with flatpak (tools), not the policy.

Let's discuss this during the meeting today.

Metadata Update from @zbyszek:
- Issue tagged with: meeting

This feels a bit like "we've been violating the policy so let's change the policy". I know it's more complex and I'm not strictly against changing policy, but we should do so for the right reasons. In particular, if we treat flatpak remotes (such as flathub) different from rpm repos (such as rpmfusion) we should be clear about both the fact and the reasons (such as legal). A policy change which makes this (the status quo) more transparent would be a good change.

I don't think we should deprioritize Fedora packages. If Fedora Flatpaks are unsatisfactory, Workstation, unlike the Atomic Desktops, can default to Fedora RPMs in Gnome Software.

And yet nobody can point to anything concrete that is wrong with Fedora Flatpaks overall, just vague accusations and assumptions.

We discussed this during the meeting today. Rough plan:
2026-03-24 18:57:03 <@decathorpe:fedora.im> 1. clarify the current policy
2026-03-24 18:57:03 <@decathorpe:fedora.im> 2. make / ask for a proposal for what needs to change
2026-03-24 18:57:03 <@decathorpe:fedora.im> 3. harmony

ACTION: $somebody needs to make a pull request to clarify/update the policy

Metadata Update from @zbyszek:
- Issue untagged with: meeting
- Issue tagged with: document it

So we had https://forge.fedoraproject.org/fesco/docs/pulls/131 which as been merged and led to https://pagure.io/fesco/issue/3585 which is discussed separately. Is there anything else left to do here? (I still need to catch up on some discussion, sorry)
Edited by siosm

I think everything is handled, so I will close this.

Metadata Update from @catanzaro:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)
Metadata
None

document it

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.