your anxiety here is actually more about flatpaks as a technology whose entire point is to be a platform for end-user application development that is base OS agnostic as possible( which is to say not as agnostic as full linux container technologies because dbus isn’t a linux kernel API..yet). It just happens to be a technology that works very well with immutable base layer distribution concepts.
We should start a separate thread where we talk about EPEL policy as a possible guide of how to restructure fedora flatpaks among some other things like end user patchability. That discussion would lead to a a series of policy and change proposals
Let’s please stay fair and not invent strawmen’s arguments. It’s ridiculous to suggest I have “flatpak anxiety” when I suggest delivering most of Fedora both as rpms and flatpaks.
Philosophically, Linux works due to choice and differentiation.
So I support the choice of Spins and Desktops SIGs to self-determine how they want to approach any issue.
Fedora has rules and such for spins, for good reason. Fedora and its spins should largely be unified as spins are promoted by Fedora.
In general, I think spins should only differ from Workstation in a single, simple way. For example, Fedora KDE is largely Fedora Workstation but using KDE instead of Gnome. Otherwise, differences should be minimized.
If the rules imposed on spins are unacceptable, then simply don’t be a spin. Fedora allows others to build on their work, ie Universal Blue.
I am not sure this would work, I don’t know if we can have the same remote twice in flatpak and have it resolve properly. But if it works, that is an option.
Actually we should talk about that…in a new thread.
What policy changes would be needed to make the Fedora project wide enough to make it possible for that work to exist and be considered a Fedora contribution.
I’m strongly supportive of this change. It’s clear enough that the Fedora user base is supportive of Flathub. Ignoring the desires of our users is not going to work this time. Integrating Flathub is critical to Fedora’s strategic direction and future growth.
Some thoughts:
Although this change proposal says that it is specific to atomic desktops, Workstation Working Group has an equivalent pending change which depends on whether or not this one is approved, so in practice it will also affect Workstation.
I would enable only the floss subset of Flathub by default. Users should be required opt-in to proprietary software sources before enabling all of Flathub, to ensure that advertisements for proprietary software remain opt-in.
I also don’t want to see open source software that’s not built from source; this is critical and we should fix it first, not later. We have a few options for how to tackle that, but the best would be to work with Flathub to either fix those apps, move them out of the floss subset (because if they cannot be built from source then they have the same characteristics as proprietary software), or create a new subset. (Workstation Working Group is watching this topic.)
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). ARM users deserve the same class of support that’s available on x86_64, and insufficient architecture support is justification to prefer a Fedora Flatpak over Flathub Flatpak on all architectures. This will also function as a small incentive for Flathub maintainers to build for all supported architectures. If Flathub supports RISC-V in the future, then we could include that here as well. Neal keeps posting his concerns about architecture support, and I hope this is an adequate compromise.
Perhaps we might have other reasons to prefer a Fedora Flatpak over a Flathub Flatpak, if there are serious quality problems with the Flathub version and efforts to work with the Flathub maintainer to fix them fail. Hopefully this should be very rare.
Not all of our outputs are equal. Fedora Flatpaks continue to fail to attract interested developers. The quality is lower than Flathub. They are, with some exceptions, not strategic. We need to change direction now. We’re at a critical moment when Linux market share is increasing significantly. Putting ideology ahead of user expectations and user experience is not a path towards success, and this would be an especially bad time to do so.
I remain concerned about this, but this is something we should attempt to fix, rather than a reason to reject the change proposal.
The equivalent change in Fedora Workstation does depend on new UX for selecting source priorities (agreement), since you pushed heavily for that.
Ive no problem with that, in fact i should have been explicit there.
I can work on this in parallel via discussions with flathub about particular sticking points here.
Changes on flathub’s side is going to take dialogue, but I don’t want perfection to be the enemy of progress here. Based on my interaction this summer, putting aside my misgivings about how my embargo was handled, which is just the resullt of inexperience on everyone’s behalf navigating an embargo, I’m confident there is intention to to handle the FOSS subset in a reasonable manner. But because we are just talking about subset curation and not inclusion in flathub itself..I dont think its something that can’t be worked out.
If we have to use an engineering control like a filter for known problematic things.. that’s probably a reasonable compromise while the dialogue is on going.
This feels like a reasonable trade-off for arch coverage. Caveat being I’m not sure full primary arch coverage as a carrot/stick is reasonable. A strict reading of that would mean because Workstation is released for Power…then this change becomes moot because flathub will not support Power ever. And in the future depending on the timing of how RISC-V bring up across the ecosystem.. the same with RISC-V. RISC-V bring up is going to be messy. Until upstream projects have risc-v runners in places like github and gitlab I’m not even sure how upstreams confidently release a risc-v anything.
If we are talking about a verified flatpak.. where the flathub is a release of the official upstream.. that sounds like a an upstream project fork situation to me..and we choose to ship the upstreamed fork. And at that point… please change the application id to avoid confusion.
if we are talking about a non-verified flatpak…
maybe we should be limiting to enabling the verified floss subset and just avoid that entirely.
If we are talking about the shared flathub runtime… that’s an interesting pickle we need to talk about.
It’s one of many statements without giving reasons. On the contrary, Flathub is outside of Fedora and there is no way of integrating “it”. What would that even mean?
Again, it’s not all black-or-white: Flathub is a different entity from Fedora, and we sure can and should work with them (too). One way is to make it easy to use Flathub flatpaks on Fedora (we ship flatpak the app and definitions), another not to duplicate work: looking at the RHEL side of things, it makes perfect sense to stop building self-contained suites/apps like LibreOffice, Firefox and GIMP in Fedora and “tell” users to get them from upstream’s (!) flatpak via Flathub. But that’s not “integrating” it, it’s leveraging it, and frees up part of our resources.
We simply cannot integrate what is outside of our control in terms of guidelines and regulations, and there’s no need to. We just have to live with headlines such as “Fedora stops shipping xy”.
$ flatpak install org.gnome.gedit
Looking for matches…
Remotes found with refs similar to ‘org.gnome.gedit’:
1) ‘fedora’ (system)
2) ‘flathub’ (system)
Which do you want to use (0 to abort)? [0-2]: 0
$ ##########
$ gsettings get org.gnome.software packaging-format-preference
['flatpak:flathub', 'flatpak:fedora-testing', 'flatpak:fedora', 'rpm']
$ ##########
$ sudo tee /etc/filterpak.filter <<EOF >/dev/null
# Allowlist style filter
deny *
allow runtime/org.fedoraproject.*
allow org.gnome.gedit
EOF
$ ##########
sudo flatpak remote-add --if-not-exists filterpak oci+https://registry.fedoraproject.org --filter=/etc/filterpak.filter
$ ##########
$ gsettings set org.gnome.software packaging-format-preference "['flatpak:filterpak', 'flatpak:flathub', 'flatpak:fedora-testing', 'flatpak:fedora', 'rpm']"
$ # (Not relevant for flatpak CLI utility, but I've checked the remote preference order in GNOME Software, working as expected)
$ ##########
$ flatpak remotes
Name Options
fedora system,oci
filterpak system,oci,filtered
flathub system,filtered
$ ##########
$ flatpak remote-ls filterpak
Name Application ID Version Branch
gedit org.gnome.gedit 49.0 stable
Breeze GTK theme org.fedoraproject.Gtk3theme.Breeze 3.22
# [...]
Fedora SDK org.fedoraproject.Sdk 43 f43
$ ##########
$ flatpak install org.gnome.gedit
Looking for matches…
Remotes found with refs similar to ‘org.gnome.gedit’:
1) ‘fedora’ (system)
2) ‘filterpak’ (system)
3) ‘flathub’ (system)
Which do you want to use (0 to abort)? [0-3]: 0
$ ##########
$ flatpak install org.kde.dolphin
Looking for matches…
Remotes found with refs similar to ‘org.kde.dolphin’:
1) ‘fedora’ (system)
2) ‘flathub’ (system)
Which do you want to use (0 to abort)? [0-2]: 0
After removing the Flatpak app from the allow list, GNOME Software doesn’t complain, neither notifies the user of any changes[1].
However, the flatpak CLI tool issues a non-fatal error, so it’s reasonable to consider that it won’t update the app in case of available updates. The workaround would currently be to reinstall the app, but that’s probably not an acceptable UX.
$ flatpak install org.gnome.gedit
Looking for matches…
Remotes found with refs similar to ‘org.gnome.gedit’:
1) ‘fedora’ (system)
2) ‘filterpak’ (system)
3) ‘flathub’ (system)
Which do you want to use (0 to abort)? [0-3]: 2
Required runtime for org.gnome.gedit/aarch64/stable (runtime/org.fedoraproject.Platform/aarch64/f43) found in remotes:
1) filterpak
2) fedora
Which do you want to install (0 to abort)? [0-2]: 1
org.gnome.gedit permissions:
ipc fallback-x11 wayland x11 file access [1] dbus access [2]
[1] host, xdg-run/gvfsd
[2] org.gtk.vfs.*
ID Branch Op Remote Download
1. [✓] org.fedoraproject.Gtk3theme.adw-gtk3 3.22 i filterpak 125.9 kB / 125.9 kB
2. [✓] org.fedoraproject.Platform.CL.default f43 i filterpak 125.3 MB / 125.3 MB
3. [✓] org.fedoraproject.Platform.GL.default f43 i filterpak 86.3 MB / 86.3 MB
4. [✓] org.fedoraproject.Platform.Locale f43 i filterpak 303.6 MB / 303.6 MB
5. [✓] org.fedoraproject.Platform f43 i filterpak 481.8 MB / 481.8 MB
6. [✓] org.gnome.gedit stable i filterpak 5.6 MB / 5.6 MB
Installation complete.
$ ##########
$ sudo tee /etc/filterpak.filter <<EOF >/dev/null
# Allowlist style filter
deny *
allow runtime/org.fedoraproject.*
# allow org.gnome.gedit
EOF
$ ##########
$ flatpak update
Looking for updates…
F: Warning: Treating remote fetch error as non-fatal since app/org.gnome.gedit/aarch64/stable is already installed: No entry for app/org.gnome.gedit/aarch64/stable in remote filterpak summary flatpak cache
Nothing to do.
$ ##########
$ flatpak install --reinstall org.gnome.gedit
Looking for matches…
Remotes found with refs similar to ‘org.gnome.gedit’:
1) ‘fedora’ (system)
2) ‘flathub’ (system)
Which do you want to use (0 to abort)? [0-2]: 1
ID Branch Op Remote Download
1. [✓] org.gnome.gedit stable i fedora 5.6 MB / 5.6 MB
Installation complete.
Fedora Flatpaks don’t support commit logs and downgrades, so I couldn’t actually test an update. I would need to find a Fedora Flatpak with frequent updates in order to properly test this in GNOME Software. ↩︎
What I intended to test above was to support my suggestion of using two remote definitions in the remotes list: one with the filtered fedoraproject.org remote (as suggested in this change proposal), with highest priority in GNOME Software, and another one with the unfiltered fedoraproject.org remote, with lowest priority.
The suggestion tried to address the scenario described by @ngompa with a Flatpak app initially making it into the filtered remote, then a couple of releases later needing to have it removed from the allowlist.
With the tests I was hoping that the Flatpak app removed from the allowlist would have still received updates, given that it was also appearing in the lower-priority unfiltered Fedora remote. The test results kind of invalidated my proposal though, the Flatpak app taken in the test wouldn’t receive any updates after being removed from the filtered remote.
It kind of makes sense in hindsight, the Flatpak tooling won’t just remove the app’s reference to the filtered remote and point it to the unfiltered one, even if they are both using the same remote URL.
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? I can think of GNOME changing the default apps (e.g. Evince and Totem being replaced in G49), but I suppose that wouldn’t need removing them from the list, if they made it into the filter.
I think that the proposal as-is is a half measure. I get the intention, but as Neal brings up there are better solutions in collaboration with app store devs and Flathub itself.
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. Fedora offers rare arches (like ppc64le) that need to be provided for as well.
Allowing Fedora deliverables to opt-out of Fedora Flatpak is effectively hitting the rare arches in the knees with a baseball bat by forcing their users to layer or just lose access to this software.
I’m with Kyle on the fact that Fedora Flatpaks are problematic, and as I have mentioned we also don’t deal with them in UM because of a lot of these issues, but there is a reason Fedora has them and allowing deliverables to opt-out causes more problems than it solves.
Consider
Improving the issues with Fedora Flatpak
Donating infra to Flathub to allow these arches to be supported
It’s pretty high. It actually has happened the last several Fedora releases now.
We’ve had the following transitions off the cuff:
File Roller removal (F34/G40)
GEdit → GNOME Text Editor (F36/G42)
Removal of GNOME Screenshot (F36/G42)
Eye of GNOME → Loupe (F39/G45)
Cheese → GNOME Snapshot (F40/G46)
GNOME Terminal → Ptyxis (F41/G47)
Add Decibels (F42/G48)
Totem → Showtime (F43/G49)
Evince → Papers (F43/G49)
The terminal transition is probably the one where the case happened where we had aborted the transition once to another app (GNOME Console). In this world, GNOME Console would have to remain in our filter list permanently.
I think it’s fairly reasonable to expect apps to churn out across Fedora releases in the future too.
Right, but all those apps provided as examples are still available in Fedora’s repos/remotes both as RPM and as Flatpak. They lost their status of GNOME default apps, but they’re still maintained. When changing Totem with Showtime and Evince with Papers in F43, for instance, both Workstation and Silverblue kept these “legacy” apps on users’ systems during major upgrades, for obvious reasons. So these apps remaining in the filtered list would ensure continuity IMO, if nothing else.
I would be more worried with apps needed to be retired for having become unmaintained, but I don’t know if such cases happened in the past with apps provided as Flatpaks. And handling such cases gracefully would probably have to be solved generally for the unfiltered Fedora remote, and not for filtered remotes in particular.
IMO, switching the default terminal is a different use case, since it’s provided in the base install and not delivered as Flatpak in the ISO image of atomic desktops. Say if Fedora was to make the switch from a legacy terminal app (gnome-terminal) to a new one (ptyxis) in the next release, and was already using filtered remotes, I suppose they would only need to add gnome-terminal to the filter (in the allowlist), so that users preferring the old terminal be able to install it as Flatpak (given that it would be removed from the base image).
There is an unspoken assumption in your comments here that this is zero sum and by enabling flathub by default on some composed Fedora project outputs it means Fedora flatpaks are going to be forcibly ended. That is not the intent at all. I do believe that Fedora Flatpaks needs to have a better scope, structure and mission than it does now.
But let me talk to the specific bit about architecture support. Individual composed Fedora outputs don’t cover secondary arches right now. Just for clarity here’s my working list of composed secondary arch outputs that informed the text of this decision.
This is one of the reasons why this is something I’m proposing that individual atomic outputs opt-in into. pppc64le isn’t currently in their scope of chosen work, and I’ve seen no discussion that it will be.
I am much more concerned about risc-v as a new arch I fully expect will become a primary arch in Fedora for some value of “soon.” In fact RISC-V support at flathub for is the thing I’m beating the drum about when I represent Red Hat in GNOME Advisory Board meetings, something I get the privilege of doing in my role as Fedora Project leader. And yes I am trying to figure out how infra can be shared as part of risc-v bring up.
