Not sure if Linux had achieved the success it has if 20 years ago communities/companies had put forward such arguments. Instead, each simply used what is most useful for themselves and exploited the flexibility that have risen from the Linux kernel and the ecosystem it is contained in. Until now, it was many Linux systems and many desktop environments. Maybe the next step is many remotes. Maybe not. But intentionally making things messy because of an opinion is not a useful test/verification, at least not in a world in which individualâs/groupâs decision making is based on imperfect information. We have to do what is best for us, may it be to team up with flathub, openSuSe (also a good idea!) or some other community or none. May it be with flatpak or something else. But the reasoning should focus on where we are and where we are going to and what is best for us and our purposes, because this is where we have most information and knowledge about. (Collaborative) Competition has to show the rest over time, and if someone else does better in some area, we might adapt, because in our dynamic and flexible realm, much is easy to adapt/change
Presume what is best for us (which is what we know most about), test/verify, and compare with others. Then adjust or not. Thatâs more useful than presuming the whole ecosystem and disrupt what feels to have not yet sufficiently proven itself. The latter is unlikely to produce useful data to go ahead with, at least imho.
Fedora will need a self-actuated reason to offer a flatpak remote. What Iâm saying is, trying to avoid conflicting with any other remote should be a non-goal. flatpak as a technology is suppose to make it possible to allow the base os (whatever that means) to move at a different speed than the applications. Thatâs the entire point. You donât even need to cross distribution ecosystems to expose the value of that.
For the sake of argument, letâs assume the only distribution ecosystem in a pocket universe is the Fedora ecosystem, which includes at a minimum Fedora, CentOS and RHEL.
For example I can imagine, and defend, a Fedora flatpak remote where application are built against a Fedora runtime composed against rawhide but run equally well on top of Fedora releases, CentOS stream and RHEL releases. I can also imagine, and defend, a similar remote offering applications built against CentOS stream runtimes that also run equally well on top of Fedora releases, CentOS stream and RHEL releases.
Thatâs more than messy enough from a flatpak remote pov.
Whatâs really crazy is, the only reason why those things in the pocket universe in my head have to be in separate flatpak remotes is because flatpak doesn, yet, expose a way for different things with the same app-id to live side by side at the same remote.
Its the one thing the linux container registries sort of do better than flatpak remotes⌠making it possible for namespaced forks of the same thing to live side by side.
If flatpak could figure out how to do that my pocket universe collapses down into a single remote that holds runtimes for CentOS stream and Fedora rawhide and there are versions of applications that target one or both of them AND users can install them side by side with each other if they need to.
This is sunk cost fallacy, if the product of that work has resulted only in worse UX and isolated Fedora as a project from other distros shipping flatpak, Iâm not sure investing more time into it is the solution.
We just had a long disagreement about 32-bit packaging with the main point being limited resources. Hereâs something that you can axe right now to free up resources with no downsides.
Letâs be clearâŚ
Itâs not the same discussion at all.
First, the 32bit discussion was focused primarily on supporting use cases that Fedora as a project cannot actually support within its bounds. Second, Fedora as a project has for years been working towards the goal of sunsetting the 32bit arch packages, in steps. Third, every arch has a build system cost, because each arch requires a significant rebuilding of binaries, each binary will want to have QA done on it.
Flatpaks have value as a set of outputs inside the scope of what the project already does with the immutable base OS outputs. Since the Fedora flatpaks are currently composed from rpm binaries that have already passed build QA, the resource burn there is much lower than a whole different arch with whole different binaries. And the immutable os deliverables that Fedora is doing does benefit. If anything I expect to see more interest in flatpaks being generated as a binary output inside this project.
For what little my opinion may be worth as a mere consumer, I think Michael Catanzaroâs proposal seems mostly good, however I think the priority should be filtered/preinstalled Fedora Flatpaks, followed by Fedora RPMs, followed by the varying levels of Flathub. This is a completely personal conjecture, but I think putting third-party flatpaks above Fedora RPMs is a mistake until whatever day RPMs are phased out, as it will harm packaging/maintenance of RPMs where Flathub has higher priority. It may not happen immediately, but psychologically RPMs may be viewed as junior-grade when they are merely available as a fallback. Why put so much effort into a package if most users will not see it and be recommended the Flathub version?
However, that doesnât omit deprecating the package and telling people to use the Flathub distributable.
So long as Fedora provides RPMs, it should know from the lessons of Ubuntu that software from outside their distributionâs domain should only take priority when thereâs a benefit. For Fedora, the benefit should be that there are fewer packages that should need to be maintained overall, allowing packaging teams to step away from the most problematic applications and put more momentum behind the most crucial components.
I thought it was because RPMs have all kinds of weaknesses that have been pointed out in this thread? For every complaint about Flathub being less than ideal there has been a response that RPMs are technically worse. Yes, Flathub sandboxing is perhaps too permissive, but RPM sandboxing isnât really a thing; it is only secure in so far as users trust Fedoraâs team and their process. (Or to use a famous quotation on this matter, âdonât trust us? We have root.â)
I presume that Fedora will need a remote for software it provides downstream support for, but Iâm not sure the point of competing with Flathub unless youâre providing something so unique that even users of other distros will choose Fedora as a source over them. If anything, I see the opposite: Users of Fedora prefer Flathub for many things because it covers what they see as weaknesses in Fedoraâs operations.
I would like to propose a compromise approach here that I raised in todayâs FESCo meeting. We (FESCo) decided to take it back to the Discussion thread for consideration prior to voting on it. Please consider.
Proposal: FESCo sets a new policy on Fedora Flatpaks: any software whose functionality must be âcrippledâ due to Fedoraâs legal requirements may not be shipped as a Flatpak. Any that do so currently will be retired in Fedora 43+. Flatpaks from Flathub will therefore simply appear in their place in the Software center as a result.
The idea here would be to acknowledge that, from the perspective of an average user, some of our software offerings may appear âcrippledâ or otherwise provide a lesser experience than upstream would prefer users to have. From my perspective, it may be acceptable for us to simply avoid shipping the Fedora versions of this software entirely.
It also acknowledges that Fedora recognizes the value of packaging software to Fedoraâs specifications in other cases: Fedora Flatpaks have a better guarantee that they are not running on ancient, unsupported platforms and that the produced binaries were built entirely in a trusted environment.
As this is discussed, please keep in mind that this proposal is intended as a compromise. That, by definition, means that no one will get everything they asked for and (likely) everyone will be somewhat disappointed by the outcome. There are no good, easy answers here.
In theory, I like this proposal. In practice, I think we need a better definition of âcrippledâ. Does the absence of several codecs which cannot be shipped in Fedora qualify as âcrippledâ? That would automatically filters out nearly all audio/video/graphic editing and reader software.
I would also add a requirement that before accepting a package in Fedora Flatpaks, if that package is already shipped in Flathub as a âofficialâ app, the packager has to obtain a write approval from project maintainers and if at a later time the project maintainers (of a package shipped officially in Flathub) formally ask us to stop shipping that package we have to comply.
These conditions (the âcrippledâ stuff too) should apply only to packages officially published in Flathub (or any other flatpak repo officially supported by upstream project maintainers).
In practice, I think we need a better definition of âcrippledâ.
I donât have a legalese definition for âcrippledâ, but my (admittedly very subjective) working definition is: âlacking functionality provided by upstream that would reasonably be expected to be available by an average userâ. So, lack of a particular video codec would perhaps not be a deal-breaker for Firefox, since video playback isnât really itâs primary purpose, but it could be critical functionality for a video player.
before accepting a package in Fedora Flatpaks, if that package is already shipped in Flathub as a âofficialâ app, the packager has to obtain a write approval from project maintainers
I think this adds an undue burden on the part of the Flatpak maintainer. I think itâs reasonable that if the upstream contacts Fedora and requests changes, the maintainer should try to implement them if possible. Upstreams cannot dictate to Fedora, but their requests should be honored where possible and we should justify when we are unable to comply.
This reads to me like a statement that we should have justification for every downstream patch that we ship as a matter of policyâŚacross the full Fedora collection. I guess it becomes a question of what justification suffices and to whom it must be justified.
Thatâs a fair question! I know that in the past, Fedora has had some contentious interactions with some upstreams. IIRC, one of the set-top media player projects went so far as to put notices on their upstream website not to use Fedoraâs RPMs because our legal policies meant that they were lacking a lot of features and the upstream was sick of getting bug reports about broken functionality that turned out to be Fedora RPM-specific.
So, I think there is definitely a discussion to be had around similar policies for RPMs, but Iâd recommend that we try not to grow this topic any bigger than it already is. For better or worse, the state of RPM packaging is very well-established at this point. If we want to make a policy change like this, letâs do it as a separate topic. Iâd also recommend waiting until the flatpak discussion concludes, since that will likely establish some precedent for the related RPM discussion.
That⌠is kind of already our policy. If we are carrying a downstream-only patch, we require a comment explaining why. Thatâs what I meant for justification: that the reasoning is maintained for future code-archaeologists. Not that it necessarily has to be a satisfying answer to every person who reads it.
Are you suggesting that the packaging guidelines as written donât equally cover both rpms and flatpaks?
Iâm assuming that particular guidance as written applies to both, even though that guidance did not anticipate the existence of a second packaging format for most of its working lifetime as packaging guidance.
If there is a need to better scope the 'thou shalt not package` restrictions, iâm not sure it behooves us to make a distrinction now between one packaging format over another.
Well, rpm packagers have the burden of a review request for the package to be accepted in the repository.
In my opinion,the difference between rpms and flatpaks is that the latter can be seen as a final, standalone product. So a software packaged as a rpm depends on / is linked to several other libraries on the system which are separate. A Flatpak can be seen as a whole, so if an official version is maintained and packaged upstream, I feel itâs different from distributing our own rpm vs a rpm built and distributed by upstream.
Anyway, if no official flatpak is distributed, I see no harm in continue providing a âcrippledâ fedora flatpak (at least, if it has basic functionality), thus my proposal of require upstream approval only if the provide an official flatpak.
Honestly Iâm wondering how far FESCo thought this through with regards to our preinstalled applications. This would notably block us from shipping Decibels and Showtime as Fedora Flatpaks. I see a few possible reactions:
Just make exceptions for Decibels and Showtime, or for all preinstalled/default apps. This would be the least-disruptive option.
Stop shipping Decibels and Showtime altogether. Fedora Workstation would just no longer support audio and video playback. Surely not a good option.
Ship the Flathub version of Decibels and Showtime instead of the Fedora version. But once we ship two preinstalled apps from Flathub, next question will surely be why not ship all preinstalled apps from Flathub?
Give up on the proposal that all preinstalled apps must be Flatpaks. This seems like the worst option as it means the apps would have to be part of the base image, which is a poor user experience. Or we could also give up on Strategy 2028âs goal of making Fedora atomic.
No, but âis not functional of usefulâ is subjective. I can make use of a video editing software which lacks a particular codec, bit someone else can consider that as "not functional ".
flatpaks right now are not standalone⌠they depend on a runtime.
the runtime are basicalty a whole bunch of individual projects smushed together into a single package.
20 years ago we could have formulated a fedora-runtime as a single rpm that had everything smushed together.. and just updated that⌠like flatpaks update their runtimesâŚand then application would just depend on that 1 rpm. But we didnt because that comes with a whole bunch of tradeoffs we were not willing to make then.
