Would buying that $1 HEVC codec off MS Store count cross-OS?
I wonder if itâs (1) technically[1] and (2) legally possible to build a Fedora Flatpak pointing to a runtime extension from Flathub. E.g. org.gnome.Showtime from Fedora referencing org.freedesktop.Platform.ffmpeg-full from Flathub. If that would be possible, my understanding is that Fedora would still provide a FLOSS, patent-free software, given that Flathub is not enabled by default, whereas having Flathub enabled explicitly by the user would provide a full, non-crippled experience.
I understand there are some limitations about the way Fedora Flatpaks are being currently built. âŠď¸
this is a difficult box for my brain to live in but I can appreciate the desire to keep the question in front of fesco scoped as small as possible. But hey you brought it up.
Ultimately what we are doing with flatpaks is introducing a new package distribution format that replaces rpms from a user perspective. We have to look at the projectwide packaging policy in that lens. I am very concerned about introducing policy that bifurcates the user experience in the project outputs. This feels like a policy that could bifurcate in a way that biases in favor of rpm.. and thatâs a problem.
I do not think it will be technically reasonable to point to an extension that is built against a different runtime.
What is possible is for us to offer a set of Fedora runtimes that apps and extensions to build against. And it might be possible to have FlatHub (or any other 3rd party) to distribute those Fedora runtimes.
I absolutely oppose this counter-proposal, and it should be rejected outright.
First off, Fedora change proposals are usually driven by âdoersâ, those doing the work. Yet for some reason, Fedora Flatpaks continue to be subject to âproposalsâ from naysayers without any engagement with or input from those who are actually involved with them. The hecklersâ veto has no place here, and on those grounds alone, this proposal should never have been made.
Secondly, it is usually beneficial to reassess any statement about Fedora Flatpaks by substituting Fedora RPMs in their place; if you would not make the same statement about RPMs, neither should you about the Flatpaks. Fedora has long deemed multimedia packages to be acceptable even if not all codecs potentially used thereby, so why does the packaging format (RPM vs Flatpak) suddenly matter?
If youâre about to answer âwell, the user can add codecs from a 3rd-party repositoryâ, stop right there, because that CANNOT be a criteria for acceptance of a package in Fedora itself. If you think about it along official policy lines, there is NO difference between an RPM and Flatpak in this case.
Furthermore, Fedora Flatpaks do now support a âBring Your Own Codecâ scheme in the form of the org.fedoraproject.Platform.Codecs extension namespace. OpenH264 is one beneficiary of that, and Iâm planning another shippable extension with extra GStreamer plugins and their deps, but itâs possible for anyone to locally import their own codecs through multiple means. (This is new and so not fully documented yet.)
Finally, the Workstation Working Group, which had previously advocated hard for Flathub inclusion, has ultimately concluded that the issues that I have raised with Flathub are systemic and on the whole it really isnât, and may never be, acceptable for promotion or inclusion in Fedora. As such, there is no way that Flathub content (on the whole) should take default precedence over Fedora content in any form, in line with previous FESCo decisions.
As I have on multiple occasions, I encourage the Workstation WG to add the ability to graphically configure repository prioritization in GNOME Software, as KDE Plasma Discover already allows.
Finally, I hope this will be the end of the ongoing attacks against Fedora Flatpaks, so that we can focus on improvements and broader involvement.
3 Likes
I am strongly of the opinion that Fedora flatpaks should cease to exist. If you want broader improvements and involvement, contribute upstream in Flathub where it benefits everyone.
11 Likes
I would like to add a thought, which is not a suggestion but just an alternative âin the middleâ that has not yet been mentioned at all:
There is not just âdo it all ourselves without synergies with others â Fedora flatpakâ or âdo outsource and impose rules we cannot influence â flathubâ but also the possibility to team up with other communities: we have already successfully collaborated with communities like openSuSE, and there is also a possibility to create a âjoint WGâ, âjoint sub-projectâ or so, in which we can mitigate concerns like âwe have no power in flathub over their rules / normsâ (we could make the rules jointly with others, on par â common consensus of parties) but also the - as far as I read it - major concern of many users who want to go to flathub: Fedora being overwhelmed with maintaining its packages with many being effectively unmaintained, not updated for long, which sometimes results in hostile dynamics between maintainers and users (the two groups often have different perceptions of appropriate compromises).
In a collaboration that is no separated project âwe subordinate our contributions toâ but a cross-project WG or cross-project sub-project, we could mitigate the maintenance issues of too many packages for too few maintainers (more or less economies of scale), but still negotiate on par with others what the norms have to be. openSuSE is just an example with whom I experienced already deep collaborations and many intertwined community members (donât know if they go a flatpak way at all).
Just a thought to be added to the discussion, though a long term one that would need much evaluation before it would be mature for any proposal 
1 Like
I think this is the central problem with this conversation which is why I am emphasizing it. Fedora has historically been a âdo-acracyâ. The people doing the work get the most say in how that technology is built and offered. The time to say ânoâ is before the technology is offered but afterwards it is mainly âhow do we make this betterâ afterwards. There are times when we end a technology but it is usually when the âdo-ersâ say âWe arenât doing this anymore.â. I mean we have been offering spins and other things which have âdeadâ upstream and few working downloads.. but as long as people keep fixing them to build, they are there.
I am saying this as someone who doesnât use flatpaks but I see someone here doing the work to try and make them as useful as they can be in Fedora. As long as Yaakov and others are willing to put in the work and are following the same rules we have in place for RPMs, I donât know what this proposal solves.
2 Likes
Everything about this discussion makes me feel like the goals of Fedora Flatpaks are not clear. We all know Fedora needs a place to pull the preinstalled system. Why redistribute software with limitations you can run a version supported from upstream atop the same base?
Is the goal to make it a resource for users for other distros as well? Is there something (such as faster deprecation of old runtimes) that would make Fedora preferable to Flathub universally? Some people seem to feel that itâs very important that users use a Firefox packaged by Fedora contributors rather than one maintained by Mozilla themselves, even though a Fedora release can not match it feature-for-feature for legal compliance. But Iâm not sure why this is so important to them.
Thereâs a philosophical issue here, part of the appeal of self-contained applications was that there was less of a âmiddlemanâ role for distros. There needs to be some sort of advantages to having a packaging pipeline for software that is already published atop the same stack from upstream sources.
Iâm just a random user, but I feel like the point of the proposal is to reduce the workload. I shouldnât guess at peopleâs motives, but I think that part of what Iâm seeing here is that people who do the work may feel defensive when told that their work is unproductive and should probably stop. If âdoersâ are the only opinions that matter, then they can vote in perpetuity to continue doing whatever it is they are doing, regardless of opinions from the people who arenât âdoingâ and are irrelevant.
However, my only âvoteâ is that Fedora has gone from one of my favorite distros in 2019 to something I only suggest with reservations today. Fedora flatpaks isnât the only reason, of course, but itâs a concern.
1 Like
I think that is a very valid question which needs to be answered. I know of at least two reasons for Fedora Flatpaks.
- There is a vested âbusinessâ interest in the primary sponsor of Fedora (aka Red Hat) to be able to have working tooling and workloads to build flatpaks that their customers can âtrustâ to have been built in a controlled environment that is externally audited to meet their needs. The methods that Red Hat does this for its customers is via RPM packages and a provable âcontinually built/testedâ plan of Fedora â CentOS Stream â RHEL. Using an RPM build method to show flatpaks being built this way might be wanted in the same ways that Fedora had modularity, pdc, podman and other Red Hat utilities in it.
- There are Fedora developers who did not for various reasons âtrustâ the Flathub method of building and distribution. These reasons ranged from: âwhereâs the sourceâ, âhow do I duplicate the buildâ, âhow do I debug and fix somethingâ to just: âwhy are we promoting something other than RPM?â.
- Probably others would go here.
Doers usually get a higher vote in matters because in the end most of this distribution is a volunteer organization. Even most of the people with @redhat.com addresses are volunteers versus paid to work on a particular package or tooling. Most of the volunteers come to do something that interests them which leads to many sub-parts which may not be what others want. [I can say there are a lot of things that I had to maintain and keep working in Fedora Infrastructure that I would have loved to shut off over my 10 years there.. things that would complicate an already complicated build system to the point of continual downtime.. other things which only 10 or 20 people seemed to use. However those 10 or 20 people were the ones doing things or it was needed for something a LOT more people depended on.]
I can say that this is something I have struggled myself with over the years for many reasons. There have been many different times over the last 3 decades I have either recommended RHL/Fedora fully, with reservations, or absolutely not. I have found that taking a vacation from the community or the distribution for a year or two is what I needed to get back into working on it. Going from various other books on volunteer organizations, this is very common with both people who use the services or help out in the services.
You are confusing the technology flatpak with the store Flathub.
Flatpak is a technology with the goal to sandbox applications and allow desktop applications to work on any distribution. It is decentralized and allows for anyone to run their own store.
Flathub is a store for flatpaks. One of its goals is to have the software creators to also maintain the flatpak. But they also allow third parties to package stuff. Its role as the de facto flatpak store (even promoted on the flatpak website) has led people to get things confused.
Fedora Flatpaks is a store of flatpaks built according to Fedoraâs phillosophies, but also inherits the legal limitations Fedora has. Fedora Flatpaks work on every distro.
Nothing universal, but principles.
Fedora Flatpaks always target the latest Fedora runtimes, so they never use EOL runtimes. Everything is built from Fedora rpms. So when a Fedora rpm gets an update, the flatpak also pulls in the updated rpms when the flatpak is updated.
In contrast, Flathub apps may use EOL runtimes and may vendor dependencies built from source or pre-compiled; when they choose to update these vendored dependencies is completely up to them, so the dependencies may be old and have security issues.
1 Like
- Back when Fedora Silverblue was just becoming a thing, Fedora flatpaks were envisioned as a mechanism for shipping some Fedora content that would normally be delivered as RPMs in Fedora Workstation. The idea was to ship a lean base system, consisting of the kernel and core userspace RPMs, and pack all of the other RPMs into Fedora Flatpaks, which unlike the system image donât require a full system reboot to update.
------------------------------ Workstation product ---------------------------------
| system RPMs (kernel, core userspace) Gnome app RPMs, Firefox RPM, Gedit RPM, etc.|
|-----System image (A/B updates)-----|-----------Fedora flatpaks--------------|
I do not consider flathub to be an upstream. I consider flathub to be a distributor. Right now they may be the preferred distributor for many upstreams, but they are not the upstream. In fact I think the winning condition for flatpak equals the sunsetting of flathub.
Flatpak as a technology is designed to be federated. I fully expect that as the flatpak technology develops further then there will be additional distributors such as github that directly competes with flathub as a distributor. We saw it happen with linux containers and I fully expect it will happen with flatpak when flatpak reaches its winning condition and upstream get access to a flatpak repo as part of hosting services.
You see flathub as a sustainable service, I donât. I see flathub as a stepping stone, something spun up with the first generation of flatpak to kickstart flatpak use⌠but I donât see it surviving in the face of something like github deciding to offer flatpak hosting as a service to projects.
Regardless of what that winning condition looks like, Fedora as a project probably has a compelling reason to build and distribute some number of flatpaks. I cannot see a future right now where Fedora chooses to pre-install any binaries built outside of the projectâs build system. And I think that is true of any binary package format that Fedora chooses to make available as an output, rpm, flatpak, container images. VM images, whatever the windows WSL Fedora runtime technically is.
So I would appreciate it if you acknowledged that is a probable reality and stop advocating that Fedora give up on flatpaks as an output. Its a viable packaging format output for the project that makes sense for pre-installation targets. And because the project pretty much allows spins of all types that could pre-install anything the project maintains, you have to accept that anything that can be packaged within the scope of the Fedora project packaging guidance may be spun out as a flatpak output at some point because someone within the bounds of the project may want to produce a Spin with it pre-installed.
Beyond the self-interest of the Fedora project itself to distribute the things it does⌠there is the issue of flatpak as a technology and where its going.
One of the things Fedora is doing with flatpaks is implementing its flatpak distribution model as OCI images.. something flathub isnât doing yet.. and if you are paying attention to what the flatpak developers are saying they want to do, the OCI stuff it is well within the scope of the direction that flatpak upstream wants to take the technology.
So if OCI is the direction upstream flatpak wants to go.. Fedora is a a little bit out in front, where Iâm very happy for the project to be actually. And like I said, the winning condition for flatpaks isnât Fedora or flathub as remotes.. the winning condition for the technology is making it possible for upstreams to be able to produce flatpaks with the ease that upstreams can output linux containers right now. Flatpak wins when there are as many version of flatpaks of a particular open source application as there are containerized versions out there of postgres right now in the public container registries. Thats what the winning condition is for flatpak.
1 Like
Yes.
As someone who sort of missed the introduction of Flatpaks in Fedora and is coming up to speed, I would agree that based on the history Iâm able to find as I research how the project got to this point, that feels right to me as an explanation.
Flatpaks makes a TON of sense as a Fedora project deliverable in the scope of the immutable base image deliverable. Once I allow my brain, which is steeped in RPM-centric lore in how to approach the problem of delivering a software collection, to flip to thinking about the collection to be delivered in immutable layers as a defining characteristic.. yes it makes sense.
Thereâs no reason for GitHub to offer that, the likely future is that Flathub evolves from just building their packages in GitHub to also hosting them as OCI artifacts on the GitHub Container Registry. This is not a huge change from how things already work today. Theyâve already delivered 3 billion flatpaks and are offering more than 3000 downloadable apps compared to Fedoraâs ~200, many of which have reduced functionality.
I canât and Iâm entirely unconvinced. They have been a net negative to the project for years now, whether through attracting legal threats or through harming user experience. Right now theyâre holding back Fedoraâs Atomic offerings by ensuring they canât compete against offerings by other distros.
This is especially bad here because Flatpak is the only way apps should be installed on these systems. I would argue this is directly harming bootc adoption by ensuring Fedoraâs bootc offerings arenât a compelling experience.
Not only can I see that future, Universal Blue managed to more than 4x Fedora Atomicâs user numbers while doing it, in only 2 years. Fedora Silverblue and Kinoite today mainly only preinstall KDE/GNOME apps as flatpaks. These are officially verified and packaged by actual KDE and GNOME developers on Flathub, preinstalling them is hardly an issue. If youâre concerned that another desktop environment doesnât have officially verified apps on Flathub, that is a great argument for Fedora to join the rest of the Flatpak community and push for itâs adoption.
It was mentioned earlier in this thread by Chris that Fedora might want to partner with another distro to work jointly on a flatpak repo, but just look at OpenSUSE. They have a similar read-only-root offering and they arenât doing their own Flatpak repo.
I think Fedora Flatpaks might make sense as a testing ground or for enterprise use cases, similar to how KDE and GNOME have their own flatpak repos for beta versions of apps, but it makes no sense as the default experience.
In the end I just want to see Fedoraâs bootc offerings succeed. Theyâre an experience worth being Fedoraâs default offering when they arenât being self-sabotaged. Itâs exactly why youâre seeing proposals like this asking for these images to get a policy exception on Flatpaks from the very people maintaining them.
13 Likes
Let me be clearer.
Other projects make other choices for their own reasons. Fedora makes choices for its own reasons.
Do specific Fedora policies impact the reach of the Fedora project outputs.. yes.. absolutely. This has been true since the founding of the project.
I donât think Fedora has ever made it a goal to be the most popular Linux distribution. It strives to be a self-sustaining distribution. And while Iâm happy to celebrate U-blueâs popularity now, seeing it be more popular than Fedora is no different to me than watching another distribution be more popular 15 years go, when we were in the middle of the last round of distribution wars, and another distribution was more popular that Fedora. This isnât at disturbing to me as you think it is.
Whatâs more disturbing to me is the idea of this project relying on binaries built elsewhere as part of the project outputs, including the installable images. if Fedora did it, would it result in a more popular Fedora? Maybe? But is it the right thing to do? Iâm not sure that the most popular path forward is always the right path forward.
I canât think of a technically sound reason to prefer open source software built in another build system as a pre-installed deliverable for a specific project. All I see is risk.
Iâm doing my best to be in a coopetive relationship with the overlapping distribution efforts and trying to avoid talking publicly about serious issues Iâm seeing in how things are being built outside of this project. Iâm doing this work quietly in a way that avoids causes reputation damage unnecessarily to peer projects. Things that I think make relying on any external build system for Fedora images a risky. If I wanted to score points off of other distributors in the ecosystem, I could be much more public about the very real concerns I have. But Iâm not interested in adding additional heat to the situation..so Iâm doing that work in private.
So in exchange for my effort to dial down the heat level here, what I could use is some grace from others to make a space for the quiet work to be done, and just agree to disagree with regard to differences in how projects in a coopetition relationship exist. Because baiting me with the popularity of how other distributors or doing things, really feels like you want me to bring the heat. I just donât understand why we keep doing this to each other.
There are real reasons why Fedora is likely never going to rely on the build system of another project as part of pre-installed materials. I really want to talk about it, but until the quiet work is done that I am engaged with right now, Iâm not going to do it and piss off other people working in the context of peer projects who are making a best effort to resolve it.
3 Likes
Iâm imagining in the future Wine will be a Flatpak and Iâll have to do my config through some other system not related to the OS. Hereâs my notes on Guild Wars 2. It says openSUSE TW, but I guarentee itâll work anywhere that has wine in PATH (a few days ago I used those notes on FreeBSD as-is 
)
I feel Flatpak is a solution to a non-desire to do traditional packaging and specific OS/conditions testing: AKA distributing to Flatpak for anyone is easier than a specific RPM on Fedora and a specific deb for Debian, and manually testing within those OSs. I feel it adds a 3rd-party layer on-top of the OS. I donât like the idea of this as itâs shifting responsibilities and reducing standards, which leads to lowers quality.
Fedora defaulting to FlatHub feels like Fedora doesnât want to maintain or put in the effort to maintain their own version for their distro. It feels like a lack-of care. But end-users want apps, and the distro needs users. Flatpak + Flathub is an easier solution to end-users of Fedora than encouraging more people to be involved or want to put in more effort in packaging RPM for Fedora.
Even though Snap on Ubuntu is similar tech, Ubuntuâs the one that made it Theyâre didnât initiate Snap to have more apps available for users as a feature, so any security benefits/etc they touted over deb seem more genuine. I feel Fedora with a goal of Atomic-default is doing it for certain reasons, and Flatpak + FlatHub earlier is a benefit.
I used Fedora primarily since 22, but stopped around F41. Iâm not a fan of Flatpak or Atomic, and feel those and certain other tech caused a rift that changed dev priorities (if not Fedora-specific then in-general that ends up on Fedora as an âupdateâ) leading to lower QA and me experiencing more issues as of late as a result (it mainly started F38/39). I have more of a philosophical issue with the proposal in-general vs technical.
One thing to keep in mind with this discussion is that Fedora is in no way trying to block users from using Flathub. Quite the opposite, over time Fedora has made it easier and easier to use Flathub.
The current status is that Flathub can be enabled on setup (at least on Workstation/Silverblue) with a button in Gnome Initial Setup and on first launch of Gnome Software.
Personally, I would like Fedora to keep to keep and improve Fedora Flatpaks as the default experience. I enjoy Fedoraâs philosophies of focusing on FOSS, secure, fully free (unpatented) software and donât think they should compromise on that vision in the default experience.
Though I am not at all opposed to Fedora making Flathub even easier to enable. The prompt to enable Flathub could be explained more clearly and practically for the end user. Though it needs to make it clear that Flathub is not supported by Fedora and that it does not follow the same security standards.
Im going to say something contraversial
Achieving quality rpm packaging is hard. There is no shame at all for people to want to avoid having to learn it in 2025 to distribute a software project to users. And I think we need to be cozignant of the fact that rpm as an available skill is on the decline in the marketplace of ideas. If youâre a 23 year old linux enthusiast today, and your interested in learning about rpm packaging, you are a rare rare breed.
And weâve seen multiple specific parts of the ecosystem avoid distribution packaging in the past, python, perl, ruby, golang, nodejs⌠like everything except C and C++ has invented a way to distribute working applications to users to avoid having to deal with distribution packaging.
I mean really the only reason its taken this long to have something that may suppliant distro packaging for desktop apps is because so much of the desktop frameworks are C/C++. If these frameworks were golang native frameworks. weâd be having a way different discussion.
Achieving quality rpm packaging is hard⌠too hard in some cases (Iâll note the golang vendoring by default change that happend recently as an example of a needed course correction to reduce the difficulty level to something reasonable) There are probably some of us who did it what we were really doing was trauma bonding in the experience.
I am not convinced that flatpaks cannot be at a higher quality and still be easier to build. But weâre gonna have to have some serious discussion about flatpak distribution policy needs to disallow.
Iâm not sure I see this sort of self-publishing you propose as easy. People who host popular OCI images frequently bemoan the monetary cost of popular registries. One of the things the âmiddlemanâ packaging that distros do provides is a way to distribute the impact of so many people downloading the same software. Distros themselves have many mirrors provided by schools/organizations to distribute the pressure on them although I donât know in this day how many users make use of them. Many of us benefit from smaller, lesser-used packages being hosted on the same infrastructure as the kernel and vim.
For me, the issue is I think Flathub is as good as any effort Iâve seen to create a distro-agnostic neutral ground for Flatpaks. Itâs guidelines arenât perfect for Fedora, but whatâs perfect for Fedora is inherently not perfect for some other distros; and any effort to level the ground among them is going to be a slight compromise for everyone except those who have no standards at all. I suppose a pessimist would say that alone means there can never be true neutrality, but I feel ideally distros would respond colaboratively toward a neutral remote for common applications. It sounds like the plan is to respond competitively, and double down on the concept of the distro providing not just your operating system but also your primary source of userspace applications. That long-standing practice was a necessity given the different configurations and versions included with different distros, but I donât think it should be a philosophical tradition.
This is the only reason I bothered to speak, because I worry that the status quo of âdozens of distro repos packaging SuperTuxKart in different packaging formatsâ being replaced with âdozens of distros packaging SKT in a common formatâ isnât much improvement. The recent 32bit discussion didnât conclude with any solutions but it did confirm that the status quo workload isnât sustainable in perpetuity, and deprecating many userspace applications may help with that.
Flathub may not meet Fedoraâs standards for itâs own included software suite, but saying âwe arenât going to provide that, youâll have to get it from somewhere else and decide if the tradeoffs of that are acceptable to youâ isnât unreasonable. Iâd rather see GNOME Web and Konqueror flatpaks with guidance to get Firefox from Flathub or wherever else Mozilla chooses to host, than preinstalled âFirefoxâ that lacks functions people may expect. At least, I think it would look better for Fedora, because âFirefoxâ may feel deceptive to users even if the license allows it. And if the Mozilla-maintained package on Flathub has some bad runtime, thatâs Mozillaâs problem, not yours.
3 Likes