You’re focused on the runtimes for some reason which I don’t understand. To be clear there is no existing conflict at the runtime level… so I have no idea what you are talking about as a matter of current practice. It feels like you are coming at this with a specific technical ask that is out of scope for what the opt-in filter will allow.
To be clear… runtimes are along for the ride. Fedora flatpaks currently does not offer a conflicting runtime that needs to be filtered. Everything in the fedora flatpaks depends on a runtime that is unique to the Fedora flatpak remote. The conflict is at the application level because Fedora offers conflicting “application” Flatpaks.
Hmm… let me be clear about the problem this filter is a compromise technical solution for…
Fedora flatpaks as currently constructed in a way that have ‘application’ flatpaks that conflict with verified upstream foss flatpaks. This conflict is contrary to the expected benefit of flatpaks as a technology. The filter is an opt-in compromise that addresses that conflict by giving Atomic outputs the choice to prefer upstream outputs.
I’m focused on the runtimes because every time I’ve seen someone criticize Fedora Flatpaks, I have looked in to the specifics of the examples they’ve provided, so that I can express an opinion on the subject that isn’t abstract.
OBS Studio is the one that comes up the most often, by far.
The problem that was cited was that the application was broken because of a bug in QT.
Because the Flathub runtimes offer something that resembles a stable release (different QT versions with overlapping maintenance windows), the OBS Studio package on Flathub could select a runtime that had a QT release that wasn’t broken.
That wasn’t possible on Fedora, because QT is a rolling release in Fedora. Fedora has multiple runtimes to select from, but they’ll all provide the same version of QT, unlike the Flathub runtimes.
The difference between Fedora flatpaks and Flathub flatpaks is that on Flathub, developers can choose org.kde.Platform:6.9 or org.kde.Platform:6.10, and they’ll get different versions of QT. The decision about when to rebase dependencies is decoupled from the user’s base OS and placed in the developer’s hands, instead. On Fedora, developers can choose between two releases, but most of the time, they’re going to get the same version of QT either way.
The stability of the components within a runtime is the issue we’re discussing here. And really, it’s the stability of QT that is at issue. There isn’t any really significant difference between the interface stability of Fedora vs Flathub runtimes otherwise.
I disagree..
its an issue you want to discuss. And its an issue I feel should be discussed in the context of a restructuring of Fedora Flatpaks strategic discussion. It’s not the issue I’m trying to address by allowing the opt-in filter.
It’s not about me or what I want, it’s about whether or not the criticism implied by the filter is constructive.
I am offering an example that identifies a specific problem and remediating conditions.
In other words: Filters should identify the discussions we need to have, because otherwise they’re just a file for people who have a grievance with Fedora having flatpaks at all.
You can’t have the discussion about this Change without dealing with the surrounding environment. You are ignoring what everyone is saying and pushing this as if it exists independent of all the things people are talking about. You are making yourself sound like you don’t care what we are saying.
The existance of restructed runtimes does not solve the problem of conflicting application flatpaks.
You seem to be disregarding my problem statement from my pov as the advocate for this change proposal. I can understand if you disagree that the problem statement or if I have been unable to adequately articulate the problem that I want to see addressed… but you are actively redefining it with your framework.
For clarity… we are now in active disagreement about what problem this change proposal attempts to address. Additional technical specifics on the problem as you define it, will likely not be constructive to discussion of the technical implementation tradeoffs for what constitutes an implementable filter. And while I understand the technical specifics of what you’re talking about, the problem you are seeing is not the problem I am trying to address in this proposal.
I am committed towards working towards addressing additional problems as part of a strategic restructuring conversation that gives fedora flatpak a better scoped mission.
I’m attempting to scope the discussion in this thread to technical tradeoffs because that is what the scope of this thread is suppose to be. Or did I misread the purpose of the Change Proposal discussion? I believe scoping discussion correctly is important.
With that said.
I already have flatpaks on the agenda for the F2F Council Summit as planned in a couple of weeks. I have every intention of addressing the environment and laying out a strategic direction with regard to flatpaks and flathub. But again, this particular change proposal discussion thread is not the correct place for the very significant discussion that will entail.
I’m not ignoring the non-technical concerns nor am I ignoring the technical concerns that are out-of-scope but relevant. I’m making sure those concerns are addressed in the appropriate strategic level project discussions that will come, regardless of the outcome of this change proposal.
If FESCo has non-technical concerns that read as philosophical or strategic project direction, I expect them to demand clarity from the Fedora Council with regard to project strategy. Since from discussion so far I am anticipating that such a demand for clarity may be asked of the Council, I have put it forward as an agenda item at the Council Summit in anticipation of such an ask.
The actual criticism implied by the filter is “this is not the upstream version that everybody other than Fedora is using.” It is inherently unfixable.
I find this list of concrete concerns very useful. As long as those concerns are not addressed, and there is no clear plan to address them, I’d be very wary to approve this change.
IIUC, we don’t have such a filter.
This would require changes in flathub that aren’t in place yet, IIUC.
I think we’ll be looking at promoting RISC-V in a not-too-distant-future. Fedora flatpaks should generally be available for RISC-V without any fuss, since the rpms are already available. But for Flathub, this is harder to predict, because changes in Flathub and some support from individual developers would be required. If we extend the policy proposed for Arm to RISC-V, it’s possible that we’d have to yank back to Fedora Flatpaks as default for many or even most flatpaks from Flathub. So switching to Flathub would create a potential problem with RISC-V adoption a year or two down the road.
So we have a number of desired external changes over which we don’t have control.
Whenever we have those discussions about Flatpak priorities and filtering, I feel like the discussion is a search for a work-around for insufficient UI in Gnome Software. For example, “it is easy to miss from which source an flatpak is installed” or “users cannot configure which upstream they prefer”. It feels like the whole issue could be made much less contentious if there was better visibility and possibility of individual choice.
Let me be clear. If you use nothing but the flatpak commandline tools for installation of software.. you still run into significant problems with confusion using flatpak applications because of how flatpak as a technology works to integrate with freedesktop standards used in the .desktop files used by all desktops.
To claim its solely a problem with GNOME software, is to misunderstand the full scope of the conflict that happens when a user installed the same application from multple remotes.
Fedora flatpaks confict with upstream flatpaks in way that rpms do not from a user perspective.. regardless of whether installation is managed by graphical application of commandline tools.
Fedora rpms and upstream flatpaks can be installed side by side.. and do show up in application menus. Fedora flatpaks and upstream flatpaks step on each other in unexpected ways due to how the .desktop files exported from flatpaks are constructed.
Flathub already has a floss subset that we can use, so this is not a problem.
Correct, this one is a problem.
Sure, but it’s not reasonable to try forcing Flathub to support a new architecture. I think my proposed policy could be extended to RISC-V only if Flathub actually supports RISC-V in the future.
This doesn’t have to be a problem. RISC-V users will still have access to RPMs. They just might have a hard time if trying to use an immutable system.
more to the point the ‘verified-floss’ exists as a flathub subset and would be most reasonable subset of flathub to turn on by default in conjunction with the use of this filter. verified-floss is intended to signify that the upstream floss project takes ownership of the application id namespace in use at flathub and is not a 3rd party supplied build. From a philosophic and strategic pov concerning fedora policy the flathub verified-floss subset are the upstream projects that fedora’s upstream-first ideal incentives us to work with, and to make considerations for, as they attempt to use flatpaks as a technology to address the entire linux desktop ecosystem as a platform.
I’ll go further, any Fedora output that chooses to make use of the filter needs to have a plan for RISC-V, as it is anticipated to be a primary arch “soon” for some fuzzy value of soon.
Thinking in terms of worse case situations, where Fedora is months ahead on RISC-V enablement. Outputs choosing to use this opt-in filter, may also choose to not have a RISC-V installable image compose and this may have the knock on consequence of not being able to meet the agreed on qualifications of “edition” at the time that RISC-V becomes a primary architecture. We haven’t done a primary arch bring up in a long time, so I expect there to be some discussion concerning how edition status interacts with this arch.
I don’t have a perfect sense of timing as to when this will come to a head. My best guess based on my current understanding of builder hardware planning (and this could be wrong.. someone else can feel free to correct me) but we have a minimum of a year before RISC-V as primary arch is an actionable concern in Fedora.
While I suppose this proposal is better than the last one, if Fedora is going filter out its own flatpaks, what is the purpose of having them in the first place?
This just seems like a strange way to phase out Fedora flatpaks or workaround an issue that should be addressed directly. Shouldn’t the decision be to either get rid of Fedora flatpaks and just use Flathub or embrace Fedora flatpaks and figure out how to make them work?
I simply don’t understand the option of having contributors continue to make flatpaks while allowing Fedora Atomic to filter them out. Fedora Atomic relies on flatpaks the most. It feels like we are saying we can’t eliminate them so let’s stop using them.
It seems like official Fedora spins should have at least a partially aligned user experience. Anyone can make a derivative distro however they want so there should be some meaning to being an official Fedora Atomic spin. It also seems like it would make it hard to write documentation or articles that broadly applied to Fedora Atomic.
On the other hand, I was testing a Fedora Atomic spin earlier today and it had no remotes enabled by default so the software store was simply empty until I went in and enabled them. That is not an ideal user experience, especially for the less technically minded user. I honestly thought it was a bug until I thought to check the settings.
I will counter that question with this…
What is the purpose of having conflicting flatpaks?
Flatpaks is intended to be a federated solution, how we are choosing to construct Fedora flatpaks puts us in direct conflict with upstreams who want to use the flatpak technology as intended, and build for the entire linux ecosystem of distributions as a single platform target.
We have to address that conflict. The opt-in filter lets us ease into addressing the problem, and will create an environment where we can discuss.. at length.. how to more optimally address that conflict by restructuring how (not why!) fedora flatpaks are constructed.. so that we are no longer in direct conflict. If we are able to make the necessary structural changes, then the existence of the filter should become moot… because we will have found other more optimal means to remove the conflict.
I’m not going to get into the value proposition of Fedora Flatpaks here. There is value there, but as long as we are constructing it in a way that is in direct conflict with upstream outputs it will be be difficult to articulate. Because right now what is blazingly obvious is that the conflict with upstream is damaging to project health, and its not clear to me that the conflict is necessary. 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.
We’ve put ourselves in a bind here because its clear we didn’t really think through how a federated flatpak environment should work to minimize conflict, before we spun up our own collection of alternative application builds. We missed something vital about what the flatpak federated landscape should be and we need to address it with some structural changes. The discussion I plan to lead will start in earnest at the Council strategic summit, from which I plan to have wider discussion to refine proposals.
To be clear, I was not intending to imply that the current situation is the correct path. Simply that the problem, whatever it is, should be addressed instead of worked around.
This, to me, this is the awkward part. By making the decision to filter the Fedora flatpaks, it seems like there is a decision implied about how this should work in the future. Using filters as a quick fix is fine from an implementation perspective but it doesn’t feel right from a decision making perspective.
Shouldn’t a path forward be defined first? Once the path is agreed upon then you can phase in the solutions. Otherwise, this becomes a first step that, at least partially, will define the future direction.
Acknowledged. In a perfect world, the Fedora flatpak spin up would have better anticipated the need to minimize conflict with upstream’s use of the technology to address Linux as a single platform. Hindsight as they say is 20/20.
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.
Does it feel a little wrong with you? I’m okay with that. It feels less wrong to me than the level of friction and heat being caused by disallowing maintainers of specific outputs who want to lean heavily into the upstream first mandate from doing that.
As I understand it, this will allow a simple “Enable 3rd party repositories” to potentially enable Flathub.
Right now, as I understand it, all the software that is enabled with “Enable 3rd party” is (potentially) proprietary, but redistributable and free to use without IP infringement.
Flathub flatpaks can easily enable individuals to install and use software that they are not legally allowed to use without sufficient notification that they may be violating the laws of their jurisdiction (I believe individuals should be able to choose whether to do so, but they must need to be informed as to what their choice may imply (including potential prosecution by the fullest extent of the law in their jurisdiction)).
A simple click of “enable 3rd party repositories” with the current wording is not that notification.
You probably need to provide another checkbox, with an appropriate (legally approved) warning message. Individuals have the right (and the expectation) to know and choose what is best for them.
There is nothing in this proposal that should be read as intended to make it possible to enable proprietary software by default. Anyone who is reading that way has either fundamentally misunderstood what the filter does, or has misunderstood how flathub organizes its contents. What I am proposing is a technical mechanism that makes it possible to choose to use flatpak outputs of upstream open source projects by default.
Please read the previous discussion in this thread. as both @catanzaro and I have pointed out, Flathub has multiple subsets defined, one of them is “verified floss,” Any one who makes use of this filter is expected to use either the “floss” subset of flathub or the “verified floss” subset. The “verified floss” subset is intended to be only open source project outputs delivered by verified upstream developers… and this is the exact subset that I feel is strategic for us to find a way to strategically partner with. I was just in another GNOME Ad Board meeting where it was reaffirmed to me that the intent of that subset is to make it possible for discerning distributors and users (like us) to be able to choice to limit access to open source.
To understand the intent of this filter you must understand that the “verified floss” subset exists, and how subsets and filters interact in flatpak.. as they are different concepts.
But let me be even clearer… if the intention was to allow proprietary, we woudln’t need this filter at all. This filter has absolutely no impact on whether we allow proprietary software by default or not. That is a separate policy discussion a policy that this changeproposal does not ask to be changed.
This filter is a compromise solution to solve exactly one problem… the open source fedora flatpaks conflict with upstream open source project flatpak outputs. We have a situation where different open source outputs conflict in a way where you can’t install both.
This is a problem for some of the existing Fedora contributors who want to build Fedora outputs that take a strong “upstream first” stance and want to build a stronger relationship with upstreams. Upstreams who now understand that they can address the entire desktop Linux ecosystem by maintaining their own verified flatpak at FlatHub. I think this opt-in filter is a reasonable compromise in the near term that unblocks The Fedora contributors who want to engage with upstream projects and support them in their goal to address the entire linux desktop ecosystem as a single platform.
Now let me put my Fedora Project Leader hat on firmly as I talk about the legal liability aspects of your concerns. My current understanding is that Fedora currently has a legal opinion that states that its legally okay to enable the entire FlatHub repository by default. What we cannot do currently is pre-install anything from FlatHub.
And I’ll go further. as the Fedora Project Leader there is absolutely no way we a sa project can provide you or any other user any assurance that what we distribute will meet legal requirements globally. That is not how geopolitics work. The best we can do is use the legal resources our sponsoring vendor, Red Hat, provides to minimize our legal liability that we cover our liability as a distributor of software. We cannot provide any assurance, nor do we provide any such assurance, that users will be able to legally use that software wherever they are across the globe. All of this is exists under very broad no warranty expressed or implied software license clauses. And while I’m sensitive to your interpretation, its not a realistic expectation on what Fedora as a project can provide as assurance. And I will not allow the project to make legal assurances to that extent because by doing so may actually create liability for the project’s sponsor.