https://fedoraproject.org/wiki/Changes/UnfilteredFlathub
Note that I am processing this proposal past the deadline because 1. I think it could reasonably be considered a Self-Contained Change proposal and 2. the reasons outlined by Mattias in another thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
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 == Fedora Workstation's existing [https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-r... third party repo feature] allows users to enable a selection of software repos that are hosted by external organizations. This selection has included a filtered version of Flathub since F35, which provides access to a small number of Flathub apps. This change would remove the filtering from our Flathub offering, so that users can enable a complete version of Flathub using the third party repositories feature. In the graphical software manager app, Flathub packages will only be selected by default when no Fedora package is available.
== Owner ==
* Name: Workstation WG * Email: mclasen@redhat.com
== Detailed Description == Since F35, Fedora has included a Flatpak repo definition for Flathub in the fedora-flathub-remote package. This Flathub remote can be used by those who enable third-party software repositories through either GNOME Initial Setup or GNOME Software. Users who do not opt in do not see any content from Flathub.
The current Flathub remote is filtered by an allowlist, to only make a limited subset of software from Flathub available.
The unfiltered Flathub change has two parts:
# Remove the allowlist from the Flatpak remote, so that when a user opts in, they gain access to all Flathub content and not just a small selection. # Adjust GNOME Software so that it uses the following priority order when deciding which package to offer by default: ## Fedora Flatpaks ## RPMs ## Flathub Flatpaks
This will mean that, when using the graphical software manager, Flathub Flatpaks will only be selected by default when there is no Fedora Flatpak or RPM.
Other details:
* In GNOME Software, users will continue to be able to manually select a different source for individual applications. * The filtering mechanism will remain in place, and it will be possible to reinstate a filter via a package update, should the need arise in the future. * It has been indicated that it is legally acceptable for us to remove the filtering from the Flathub remote that we make available for users to opt into. * The UI for enabling the third party repositories clearly states that they contain proprietary software. * GNOME Software shows information about whether apps are open source or proprietary, so that users can decide whether they want to install them or not.
== Feedback == A previous version of this proposal was rejected by FESCo for Fedora 37. It has subsequently been modified to address the concerns raised:
* GNOME Software will prefer packages that have been through the Fedora packaging process, over those that have not. * For developer tools that do not work well in a sandbox, there will be no Fedora Flatpak, and the RPM will be preferred over the Flathub Flatpak.
Some other questions and concerns that were raised in the previous discussion:
=== Who owns and runs Flathub? ===
Flathub is owned and run by [https://foundation.gnome.org/ the GNOME Foundation], which is a 501c(3) organization registered in the USA. (The GNOME Foundation [https://foundation.gnome.org/legal-and-trademarks/ owns the Flathub trademark], and employs one of the sysadmins who works on Flathub.)
As a non-profit, the GNOME Foundation is required to fulfill a charitable purpose. This is set out in its IRS registration, which states that the organization's mission is "broadening access to technology through the development and distribution of... usable free computer desktop software".
The GNOME Foundation is governed by its Board of Directors, which is elected by contributors to the GNOME project.
Plans exist to create additional governance around Flathub itself, so that other desktops and projects have a formal role in the running of the Flathub service.
=== Isn't Flathub full of repackaged binaries? ===
At present, around 10% of the apps on Flathub have been repackaged from another format. These other formats include distro packages and tarballs, as well as binaries. (The previous figure was 12% - the analysis for this can be read [https://blogs.gnome.org/wjjt/2022/06/14/how-many-flathub-apps-reuse-other-pa... here].)
Flathub prefers that apps be built from source, and if sources are available this is what it is expected to be used. Repackaging is only used when sources aren't available, or when it isn't practical to build the entire application, due to size constraints.
=== But I don't like Flatpak because ___________ ===
Inevitably, people have opinions about the design choices for Flatpak - no technology is ever perfect. Nevertheless, Flatpak is a unique opportunity for Fedora. Some of the key advantages it offers:
* Allows supporting the same app over multiple OS versions * Is compatible with next-generation image-based operating systems, like Silverblue * Vibrant upstream application ecosystem, particularly around Flathub * Distro and platform neutral with no vendor lock-in * Support for application confinement/sandboxing * Fully integrated into the GNOME desktop experience
No other application packaging tool has these qualities and, for all these reasons, Flatpak is an important part of the long-term plans for Fedora Workstation.
=== Lack of community presence around Fedora Flatpaks ===
We previously received feedback that there were no good contact points for Fedora Flatpaks. The newly created [https://fedoraproject.org/wiki/SIGs/Flatpak Fedora Flatpak SIG] aims to correct this situation, and will be the group that is responsible for Fedora Flatpaks in the future.
The SIG will work to improve the general state of Fedora Flatpaks, including documentation, issue tracking, and coordination.
== Benefit to Fedora ==
Flathub currently hosts nearly 2,000 apps, including many apps which are not included in the Fedora repositories. This includes popular proprietary apps, but also many open source apps which are maintained in Flathub by their developers. This change will make it easier for Fedora users to access this resource.
For users who already use Flathub, this change will make it easier to setup.
Additionally, out of the box application availability is one of the key metrics on which Fedora is judged in comparison to other distros. Having the option to easily enable Flathub will put us in a much more competitive position with regards to our rivals, and will make it easier for people to recommend Fedora as a user friendly Linux distro.
This change will also be a significant improvement over the existing filtered version of Flathub that we offer. This has received a lot of negative feedback, with users being confused by the limited subset of Flathub that are included.
== Scope == * Proposal owners: ** Remove the allowlist in /usr/share/flatpak/fedora-flathub.filter, or replace it with one that allows everything ** Adjust the name of the remote to reflect its unfiltered nature
* GNOME Software developers: ** Land this change to fix preference order in g-s: https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1511 ** Make sure that the preference order works as desired on Silverblue as well, where we always want to prefer flatpaks over layering rpms. This is being discussed here: https://github.com/fedora-silverblue/issue-tracker/issues/354
* Release engineering: ** No work needed
* Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives:
== Upgrade/compatibility impact == Existing Fedora installations with a configured Fedora Flathub remote will pick up the new, permissive filter.
== How To Test ==
When third-party software is not enabled in GNOME Initial Setup or GNOME Software, search results from Flathub should not appear in GNOME Software.
When third-party software is enabled in GNOME Initial Setup or GNOME Software:
* Search results from Flathub should appear. * The default app selected by GNOME Software should be as follows:
{| class="wikitable" style="margin:auto" |- ! Fedora Flatpak? !! RPM? !! Flathub Flatpak? !! Default package |- | ✓ || ✓ || ✓ || Fedora Flatpak |- | ✗ || ✓ || ✓ || RPM |- | ✗ || ✗ || ✓ || Flathub Flatpak |- | ✓ || ✓ || ✗ || Fedora Flatpak |- | ✓ || ✗ || ✗ || Fedora Flatpak |- | ✗ || ✓ || ✗ || RPM |}
== User Experience ==
When opening GNOME Software after opting into 3rd party software, all the applications that are available on Flathub will show up in search results.
Where there are overlaps, Fedora content will be preferred over Flathub content.
When opening GNOME Software without opting into 3rd party software, only Fedora content will be show up in search results.
== Dependencies == No dependencies.
== Contingency Plan ==
* Contingency mechanism: Reinstate the filtering we had in Fedora 36
* Contingency deadline: Beta
* Blocks release? No
== Documentation ==
* [https://pagure.io/fedora-third-party/blob/main/f/doc/fedora-third-party.1.md fedora-third-party] * [https://github.com/flathub/flathub/wiki Flathub wiki] * [https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remotes... Comparison of Fedora Flatpaks and Flathub remotes]
== Release Notes ==
The Fedora Flathub remote now exposes all content from Flathub, instead of only a small subset. Flathub is not enabled by default. To enable software from Flathub, turn on third-party software in GNOME Initial Setup or GNOME Software.
On 10/01/2023 19:33, Ben Cotton wrote:
In the graphical software manager app, Flathub packages will only be selected by default when no Fedora package is available.
Thanks for implementing that. Looks good for me now.
On Tue, Jan 10, 2023 at 4:58 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 10/01/2023 19:33, Ben Cotton wrote:
In the graphical software manager app, Flathub packages will only be selected by default when no Fedora package is available.
Thanks for implementing that. Looks good for me now.
Indeed, this is exactly what we were looking for.
On Tue, Jan 10, 2023 at 7:34 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/UnfilteredFlathub
Note that I am processing this proposal past the deadline because 1. I think it could reasonably be considered a Self-Contained Change proposal and 2. the reasons outlined by Mattias in another thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
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 == Fedora Workstation's existing [https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-r... third party repo feature] allows users to enable a selection of software repos that are hosted by external organizations. This selection has included a filtered version of Flathub since F35, which provides access to a small number of Flathub apps. This change would remove the filtering from our Flathub offering, so that users can enable a complete version of Flathub using the third party repositories feature. In the graphical software manager app, Flathub packages will only be selected by default when no Fedora package is available.
I appreciate the work that will go into making sure that software provided by Fedora will always take priority over third-party flatpaks, thank you for working on that.
Also, given that it is now apparently considered "allowed" to enable unfiltered flathub with the "Enable third-party repositories" switch, I wonder if that reasoning also applies to the equivalent situation for RPMFusion repos? The "Enable third-party repositories" switch only enables "filtered" repos (containing only RPMs for proprietary NVidia drivers and the Steam client), so following the same reasoning, it should now be possible to enable "unfiltered" RPMFusion repos with that switch instead, as well?
Fabio
On Wed, Jan 11 2023 at 01:33:18 AM +0100, Fabio Valentini decathorpe@gmail.com wrote:
Also, given that it is now apparently considered "allowed" to enable unfiltered flathub with the "Enable third-party repositories" switch, I wonder if that reasoning also applies to the equivalent situation for RPMFusion repos? The "Enable third-party repositories" switch only enables "filtered" repos (containing only RPMs for proprietary NVidia drivers and the Steam client), so following the same reasoning, it should now be possible to enable "unfiltered" RPMFusion repos with that switch instead, as well?
This is only allowed for RPM Fusion's NVIDIA driver repo.
On Wed, Jan 11, 2023 at 1:59 AM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Wed, Jan 11 2023 at 01:33:18 AM +0100, Fabio Valentini decathorpe@gmail.com wrote:
Also, given that it is now apparently considered "allowed" to enable unfiltered flathub with the "Enable third-party repositories" switch, I wonder if that reasoning also applies to the equivalent situation for RPMFusion repos? The "Enable third-party repositories" switch only enables "filtered" repos (containing only RPMs for proprietary NVidia drivers and the Steam client), so following the same reasoning, it should now be possible to enable "unfiltered" RPMFusion repos with that switch instead, as well?
This is only allowed for RPM Fusion's NVIDIA driver repo.
Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of ffmpeg and so on. Why is it ok now to get these from flathub, but not from RPM Fusion?
On Wed, Jan 11, 2023 at 2:44 AM Alexander Ploumistos < alex.ploumistos@gmail.com> wrote:
Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of ffmpeg and so on. Why is it ok now to get these from flathub, but not from RPM Fusion?
I guess the difference could be between a general-purpose app store, and a collection of apps "not allowed in Fedora". IOW there is a different purpose of existence. I'm not a lawyer, though. It's definitely a good question to raise.
On Wed, Jan 11 2023 at 02:44:01 AM +0100, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of ffmpeg and so on. Why is it ok now to get these from flathub, but not from RPM Fusion?
Hi, it's because RPM Fusion is explicitly designed to provide extra packages for Fedora, whereas Flathub is not. Apparently Fedora Legal is now OK with Flathub risk, but not with RPM Fusion risk. So there you have it.
Specific packages from RPM Fusion might still be allowed if split into separate repos that don't provide access to the rest of RPM Fusion, so that Fedora Legal can review them individually. So far, this has only been used to allow the NVIDIA driver.
Michael
On Wed, Jan 11, 2023 at 10:47 AM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Wed, Jan 11 2023 at 02:44:01 AM +0100, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of ffmpeg and so on. Why is it ok now to get these from flathub, but not from RPM Fusion?
Hi, it's because RPM Fusion is explicitly designed to provide extra packages for Fedora, whereas Flathub is not. Apparently Fedora Legal is now OK with Flathub risk, but not with RPM Fusion risk. So there you have it.
Specific packages from RPM Fusion might still be allowed if split into separate repos that don't provide access to the rest of RPM Fusion, so that Fedora Legal can review them individually. So far, this has only been used to allow the NVIDIA driver.
... and Steam
On Wed, Jan 11, 2023 at 4:47 PM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Wed, Jan 11 2023 at 02:44:01 AM +0100, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of ffmpeg and so on. Why is it ok now to get these from flathub, but not from RPM Fusion?
Hi, it's because RPM Fusion is explicitly designed to provide extra packages for Fedora, whereas Flathub is not. Apparently Fedora Legal is now OK with Flathub risk, but not with RPM Fusion risk. So there you have it.
Specific packages from RPM Fusion might still be allowed if split into separate repos that don't provide access to the rest of RPM Fusion, so that Fedora Legal can review them individually. So far, this has only been used to allow the NVIDIA driver.
Thanks Michael, what a headache. So for RPM Fusion to be included, it would have to change its scope/definition and host a more "varied" suit of packages?
Once upon a time, Alexander Ploumistos alex.ploumistos@gmail.com said:
Thanks Michael, what a headache. So for RPM Fusion to be included, it would have to change its scope/definition and host a more "varied" suit of packages?
Probably, but there's no reason for RPM Fusion to expand the scope beyond "things that can't be in Fedora for legal/policy reasons".
On Wed, Jan 11 2023 at 05:19:03 PM +0100, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
Thanks Michael, what a headache. So for RPM Fusion to be included, it would have to change its scope/definition and host a more "varied" suit of packages?
Well I can't be certain what Fedora Legal will or won't accept, but I don't think so.
I think we've hit the bounds of what can usefully be discussed on the mailing list, so feel free to continue via private mails if desired.
Michael
On Tue, Jan 10, 2023 at 7:50 PM Ben Cotton bcotton@redhat.com wrote:
# Adjust GNOME Software so that it uses the following priority order when deciding which package to offer by default: ## Fedora Flatpaks ## RPMs ## Flathub Flatpaks
Thanks for this. That was my concern last time. With my QA hat on, I think this is good to go now.
The one concern I have with this proposal is it says that flatpak version would only be offered if it didn't duplicate a package in fedora. The potential problem I see is this depends on Fedora and Flathub being totally consistent in their naming.
On Wed, Jan 11, 2023 at 7:22 AM Neal Becker ndbecker2@gmail.com wrote:
The one concern I have with this proposal is it says that flatpak version would only be offered if it didn't duplicate a package in fedora. The potential problem I see is this depends on Fedora and Flathub being totally consistent in their naming.
Flatpaks require RDNN naming (because AppStream does), which is often part of the upstream source code already for AppStream data. So this is *usually* not an issue.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 11/01/2023 13:20, Neal Becker wrote:
The potential problem I see is this depends on Fedora and Flathub being totally consistent in their naming.
Both RPM and Flatpak use the reverse domain ID from the upstream-provided metainfo file.
On Wed, Jan 11, 2023 at 1:22 PM Neal Becker ndbecker2@gmail.com wrote:
The one concern I have with this proposal is it says that flatpak version would only be offered if it didn't duplicate a package in fedora.
Citation needed. Do you mean this sentence?
Where there are overlaps, Fedora content will be preferred over Flathub
content.
That has a completely different meaning than what you wrote. It says Fedora content will be offered by default, but it doesn't mean the Flathub content won't be available. In gnome-software, you'll still be able to select and install the Flathub package, if you so desire.
I am wholely against this.
One of the primary reasons I use Fedora is because it only ships free software repos by default. Indeed, the first of the Four Foundations is Freedom, which explicitly lists these as part of the foundation:
• “innovation in free and open source software that can equal or exceed closed source or proprietary solutions;
• “and, a completely free project that anyone can emulate or copy in whole or in part for their own purposes.”
Providing nonfree packages out of the box ultimately promotes the use of that nonfree software, which violates this foundation.
I agree that Fedora Flatpaks aren’t really successful, but the solution is not enabling unfiltered Flathub.
Cheers,
On Wed, Jan 11, 2023 at 2:37 PM DJ Chase u9000@fedoraproject.org wrote:
Providing nonfree packages out of the box ultimately promotes the use of that nonfree software, which violates this foundation.
It's not out of the box. You have to *opt-in* to third-party repos (which already contain Steam, Nvidia binary driver, etc).
On Wed Jan 11, 2023 at 9:33 AM EST, Kamil Paral wrote:
It's not out of the box. You have to *opt-in* to third-party repos (which already contain Steam, Nvidia binary driver, etc).
Then in that sense, aren’t we already shipping unfiltered Flathub? IIRC you can already enable Flathub in GNOME Software.
Cheers,
On Wed, Jan 11, 2023 at 10:09 AM DJ Chase u9000@fedoraproject.org wrote:
Then in that sense, aren’t we already shipping unfiltered Flathub? IIRC you can already enable Flathub in GNOME Software.
The first two sentences of the proposal summary are "Fedora Workstation's existing third party repo feature allows users to enable a selection of software repos that are hosted by external organizations. This selection has included a filtered version of Flathub since F35, which provides access to a small number of Flathub apps."
Enabling Flathub in GNOME Software currently does not give an unfiltered Flathub. It's a filtered view, manually curated. See https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications for more context.
On Wed Jan 11, 2023 at 10:18 AM EST, Ben Cotton wrote:
The first two sentences of the proposal summary are "Fedora Workstation's existing third party repo feature allows users to enable a selection of software repos that are hosted by external organizations. This selection has included a filtered version of Flathub since F35, which provides access to a small number of Flathub apps."
Enabling Flathub in GNOME Software currently does not give an unfiltered Flathub. It's a filtered view, manually curated. See https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications for more context.
True, but it was my understanding that “our Flathub offering” in “This change would remove the filtering from our Flathub offering” refers to Fedora Flatpaks, which is enabled by default, not the filtered view of Flathub that can be enabled in settings
Is that correct?
Cheers,
On Wed, Jan 11 2023 at 03:47:41 PM +0000, DJ Chase u9000@fedoraproject.org wrote:
True, but it was my understanding that “our Flathub offering” in “This change would remove the filtering from our Flathub offering” refers to Fedora Flatpaks, which is enabled by default, not the filtered view of Flathub that can be enabled in settings
Is that correct?
No. There are no Fedora Flatpaks on Flathub, and there are no filters to prevent users from installing Fedora Flatpaks.
Michael
On Wed Jan 11, 2023 at 10:56 AM EST, Michael Catanzaro wrote:
No. There are no Fedora Flatpaks on Flathub, and there are no filters to prevent users from installing Fedora Flatpaks.
Oh ok; I have no objection then. Apologies for the confusion.
Cheers,
One thing I don't see addressed here is how this would impact the release criteria. Would it? If so, now's the time to start coordinating with the QA team to make those changes.
On Wed, Jan 11, 2023 at 5:26 PM Ben Cotton bcotton@redhat.com wrote:
One thing I don't see addressed here is how this would impact the release criteria. Would it? If so, now's the time to start coordinating with the QA team to make those changes.
I think we're mostly concerned with the default experience, i.e. without third-party repos enabled. But the toggle should definitely work, since it's offered by gnome-initial-setup. So from the QA perspective I think we'll be mostly focusing on whether the repos are enabled correctly if the toggle is used, and whether the gnome-software prioritization approach (Fedora before Flathub) works properly. At this moment, I don't see any effect on our existing release criteria, but if anyone sees something, please speak up.
-
Alexander Ploumistos -
Ben Cotton -
Chris Adams -
DJ Chase -
Fabio Valentini -
Kamil Paral -
Michael Catanzaro -
Neal Becker -
Neal Gompa -
Stephen Gallagher -
Vitaly Zaitsev