We've received complaints from multiple upstream developers, most recently from OBS Studio, regarding users experiencing quality issues when using Fedora's flatpak app. This is because of the order of precedence in GNOME Software:
Fedora Flatpaks > Fedora RPMs > Flathub
Unfortunately Fedora Flatpaks have been a significant source of quality problems and have frankly been generally unsuccessful. Fedora Flatpaks are not well-tested, and users who understand what they are generally do not want to use them. They want to use higher-quality Flatpaks created by upstream instead. But most users don't even realize they are getting a Flatpak from Fedora rather than from upstream, which can result in considerable confusion.
I want to completely change the precedence in GNOME Software to:
Flathub > Fedora Flatpaks > Fedora RPMs
However, FESCo approved inclusion of Flathub on the condition that it is the lowest-priority source (original proposal), so we would want to go through the change proposal process to propose changing this.
Alternative 1: Fedora RPMs > Fedora Flatpaks > Flathub, but this is not desirable because it underestimates the importance of Flatpak sandboxing and prevents us from ever reaching our desktop security goals. I will write some blog posts about this eventually.
Alternative 2: just remove the Fedora Flatpak remote by default. However, we really do need Fedora Flatpaks for at least GNOME core applications to implement https://pagure.io/fedora-workstation/issue/269 so this would not be an ideal outcome. But perhaps we could create separate Flatpak remotes for preinstalled Flatpaks vs. everything else.
Alternative 3: make it user-configurable like Plasma Discover does. This is pretty much the only option I will accept. If users want Flathub first, they should be able to configure it from the UI.
That's not really an alternative default behavior though. I'm proposing to change the default behavior. I agree that it's time to expose precedence configuration in GNOME Software.
I disagree with the assertions that "Fedora Flatpaks have been a significant source of quality problems" and that Flathub Flatpaks are always "higher-quality". A lot of work has gone into these, fixes have been applied as issues have been brought to my attention, and further improvements are soon on the way.
Many of these complaints would apply equally to the RPMs. I see this as no different than the Bottles fiasco from earlier. If software is FOSS then by definition we must have the right to redistribute it as we please, and upstreams cannot restrict that and remain FOSS. As such, I don't think we should need to entertain any such "requests" by upstream to not distribute "their" software in whichever form it may be. (Personally, I take a very dim view on such "requests".)
Based on what I've seen in discussions along these lines, what we have is a new era in which upstreams now believe that, thanks to Flathub etc., they don't need distributions anymore for their software to reach users, no longer see the value in distributions, and simply wish to cut out the "middleman" entirely. However, that does not give them the right or power to do so.
IMO FESCo was correct to put Flathub as lowest-priority, as we have no control over what goes into them, and their packaging standards are low, inconsistent, or nonexistent. That's not to say that there isn't useful content there, but priority should definitely be given to our own builds.
Instead, we should try to get more involvement in the development and testing of Fedora flatpaks (and recently we have had someone besides myself actually testing updates), and address whatever legitimate issues exist in our packaging (if any) through the usual bug reporting process.
To bring up an example of a problem which only affected users of the Fedora Flatpak, but not the upstream Flathub Flatpak or (most) users who installed from RPM: https://bugzilla.redhat.com/show_bug.cgi?id=2327310
A bug in the RPM packaging meant that the runtime image loaders dependency of Fractal was missing from the specs, possibly due to the packager not looking closely enough at dependency changes when handling a version bump. This issue probably wasn't found during testing because all of the testers had Loupe installed on their system, which caused the image loaders to be available.
However, the Fedora Flatpak build of Fractal installed a minimal set of dependencies, and so was missing the image loaders. The Fedora Flatpak was apparently not properly tested, and was released with a significant bug where it could not display images.
The upstream Flatpak on Flathub was properly tested by the developers, and included all the components needed for correct functionality.
During the period when this broken Flatpak was available, a number of people came to the Fractal matrix channel looking for help. The response given to them was almost universally "The Fedora Flatpak is broken, switch to Flathub and report a bug to Fedora".
Eventually one of them finally did report the bug, but it took a lot of convincing to get people over the hurdle from "asking a casual question on Matrix" to "formally reporting an issue on a downstream bug tracker" :/ There's probably something that can be improved here with directing users to Fedora's user support channels and having a less formal issue reporting process.
That's a great example of breakage caused by the Fedora Flatpak (although it was also pretty easy to fix).
Here are a few more alternative proposals, based on a suggestion by kepstin in Matrix:
Alternative 4: Verified Flathub > Fedora Flatpak > Fedora RPM > Unverified Flathub
Alternative 5: Verified Flathub > Fedora Flatpak > Unverified Flathub > Fedora RPM
That wasn't really a flatpak issue though, it was just less likely to be noticed in RPM installs. In any case, once brought to our attention, it was quickly and easily fixed. WIth more usage and proper bug reporting, issues will quickly diminish.
I would like to provide my thoughts, as someone who uses Fedora as a developer (working with applications), and an end user: Fedora Flatpaks are not the way.
Fedora Flatpak advocates can push the idea that "Our way is good, developers are wrong, we should fully exercise our rights as open source licenses gives us", absolutely. But that doesn't mean it's a good idea. Just because you can, doesn't mean you should. Fedora Flatpaks do not get nearly enough testing to justify shipping them, and the lack of working with upstream developers is part of the entire reason Flatpaks exist in the first place.
Fragmentation is not something to be taken lightly. If Fedora doesn't have a reason for Fedora Flatpaks other than "we're allowed to do this", I don't believe Fedora Flatpaks are justified. Arguing that Flathub is supposedly not up to par in terms of software review is a horrible argument to use, because filtering Fedora to allow Verified Flatpaks by default rather than just Flathub as a whole can get a pretty reasonable result out of this.
I would appreciate it if end users didn't have to disable Fedora Flatpaks and then add unfiltered Flathub to get working applications, but I understand that won't happen, exactly like that. Having Verified Flathub as the primary source already gets things a lot further, because a lot of applications users would use have a pretty good chance at being Verified, and this not only makes it easy on the end user (apps have a better chance at working), but also developers, as they know where their users are pulling their app from.
By that logic, we shouldn't package RPMs either for anything which is on Flathub, and we've in fact had -- and ultimately rejected -- such claims before (e.g. bottles, which was only an RPM).
If those Flatpaks are verified, then yes, that would make sense. Especially when those developers have stated their issues with distributions packaging them, and distributions very clearly cannot catch up with those applications. Bottles has had this problem with Fedora (where it was unmaintained, and broken), and Arch (which attempts to ship it, but can't, due to requiring specific versions of libraries that Arch cannot provide).
You're attempting to justify packaging programs without also seeing that you packaging things breaks them. If you recognize that, things become a million times easier,
You're ultimately saying we should tell contributors to not contribute things to Fedora. That's not a proposition that will ever go over well.
I'm saying contributors should attempt to prefer contributing directly to upstream if at all possible. The more efforts spent on improving upstream development, the less effort spent on ensuring unofficial packaging doesn't break, and the better upstream software becomes.
The problem with your assertion is that the alternative isn't contributing to upstream, it's not contributing to anything at all. For example, I don't contribute to any project I can't package and maintain in Fedora. My experience and my ability to work on things is limited, and I learn and contribute to things through my work on Fedora. You take that away from me, and I'm done with FOSS. I don't have anything left to do or give.
There are also people that package things for Fedora because it's a relatively low bar compared to upstream software development and it helps them learn how software is put together and eventually become productive as a voice of feedback or even doing little fixes here and there.
That's your problem. Not everybody should have to work around what you want. If somebody is going to package something, they should first ask developers about it - because they'll know what to do best, what the software requires, the works. Fedora has been nothing but anti-upstream in regards to working with application developers.
I'd like to chime in and mention that I'm really appreciative that this issue is being brought up as the poor implementation of Flatpak repo priority is probably one of the very few pain points I experience in Fedora which is otherwise close to perfect. Part of my setup process every time I use Fedora has to involve fixing the Flatpak situation as I otherwise run into snags that are usually already solved.
I see some significant drawbacks to the way things are implemented currently, all of which do a disservice to users at the end of the day.
1) Officially packaged Flatpaks from Flathub don't get used, instead unofficial Flatpaks from Fedora get pulled in which I'm comfortable saying is almost never what the user actually wants, and it also decreases the consistency in software functionality that is expected from the current package published by upstream. Bugs that exist in the Fedora Flatpak builds that simply don't need to exist.
2) As a whole, the scope of Flathub allows for a unification of software sourcing, a one-stop-shop that is implemented in so many distributions, something which as a whole has been a sore spot for end users on the Linux Desktop for quite some time. Current versions of official software as a standard. I would make the case that Fedora's resistance to supporting this and instead duplicating effort while deprioritizing Flathub does a disservice to their users as well as the entire Linux ecosystem.
3) Assuming the current order is Fedora > RPM > Flathub, this order of priority is incredibly backwards to the notion of isolating applications from the core system when possible, and introduces a higher likelihood of system-level breakages any time a package not in the Fedora Flatpak repo is installed and it falls back to RPM and touches the system package manager.
Lastly: while I'm sure there are some users that do specifically want the Fedora Flatpak, it's safe to say that having the expected, unified default for Flatpaks be prioritized is unlikely to impact those users as they're undoubtedly the type of users inclined to specifically select their software from specific sources.
IMHO the point of a distribution is to, among other things, provide a curated collection of software. If I install a RPM from Fedora, I can be reasonably confident the license will be sane, that it will have been built from source of verifiable origin and that it shouldn't break things too badly. If it does, I have a single point of entry for filing bugs, and a process to escalate them if they're important enough and don't get sorted out. Flathub hosts everything and anything, with, in my experience, little curation around licensing, provenance or quality. I agree with @yselkowitz when he said earlier
As for
Fedora has been nothing but anti-upstream in regards to working with application developers.
This has not been my experience at all, both as an upstream and as a Fedora packager involved in multiple SIGs. While there's certantly points of friction, in general upstreams are happy to have an additional distribution channel through Fedora, and will work with packagers on adjusting things as needed; conversely, it's quite common for packagers to get involved upstream, often directly working to fix issues that come up during integration.
Taking a step back though, I don't think these kind of generalizations are conductive to having a productive discussion. @catanzaro mentioned complains about OBS Studio -- do we have a list of packages coming from Fedora Flatpaks that folks have had issues with? This seems like a good place to start to evaluate if we need to do something differently.
What you should be doing differently is not provide a Fedora Flatpak if an official Flatpak is available. Trying to fix every Fedora Flatpak is not a feasible solution, when you'd be doing that often, for every single Flatpak.
I'm probably in the minority here but as a Fedora user, I actually generally prefer Fedora flatpaks over the Flathub version unless there are clear differences in functionality such as in the case of OBS that triggered this issue:
This in no way minimizes the real concerns raised by upstream developers. However, a categorical claim that Flathub apps are generally of higher quality than the Fedora version needs justification. Keep in mind that Fedora Flatpaks are basically just Fedora RPMs in a sandbox, so whatever problems alleged of Fedora flatpaks will often apply to the corresponding RPMs and vice versa.
It might be helpful to first enumerate a concrete list of apps available as RPMs, Fedora flatpaks, and Flathub flatpaks, and compare their functionalities. The data could suggest a more nuanced approach than a general preference of one software channel over another.
My first thought is that this is all incredibly similar to the so-called browser wars where at some point Microsoft Windows made Internet Explorer a part of the OS so that it could not be removed, and similarly how later Android made Chrome its default that ended up killing almost all other competition.
This was followed up by anti-trust regulations in Europe (and probably in other parts of the world too that I don't know as well) and forced the OS manufacturers to ask users what browser they want to install, instead of just picking a default.
I think we are in a similar situation here and maybe the right choice for users would be to let them choose during initial setup what package repositories they want to have enabled. Note that I said "for the users" - the answer would most likely be different if we look at it from let's say Fedora's point of view where it would be clearly beneficial to promote its own repo over others, and similarly from flathub maintainers perspective who'd want to have their repo promoted.
I think for users a choice would make most sense.
Only experienced Linux users would be able to make that choice, though. The overwhelming majority of new users are not going to have any clue how to answer when asked which software sources to prefer, especially not during initial setup (before they even know how Linux works, basically the worst possible time).
I would make user configuration easier by exposing the existing packaging-format-preference setting in the GNOME Software preferences dialog, so users can override what we choose. This setting is important enough to expose more prominently. But we should still make a default choice that is most appropriate for most users, and not ignore our responsibility to pick good defaults.
On my current attempt to main Silverblue (gave up last time due to too many rough edges), I'm running these apps from Fedora flatpaks:
all of those work fine and do their jobs. I'm not sure a couple of bugs justifies the "significant source of quality problems and have frankly been generally unsuccessful" claim. Of course, this also means I'm testing all those flatpaks.
I'm also running some apps from Flathub and those are also working fine. But I do kinda instinctively prefer the Fedora Flatpak when one is available.
It's not necessarily the wrong idea to decide to give up on Fedora flatpaks and just live off Flathub, but I'm not sure I'm buying the justification based on my experience.
As it happens, I reinstalled Fedora on my daily driver last week, and by far the most time-consuming aspect in setting things back to the way I had them was manually clicking the dropdown in GNOME Software to change the installation source for all the Flatpak apps I use (which are essentially all the apps on my system). I specifically want the upstream version from Flathub, so I can get the latest updates directly from the developers, and am not personally interested in using the versions packaged by Fedora.
I will also add that I have advocated for adding the ability to expose the setting to allow users to set a default software source in GNOME Software before.
I work for RH on flatpak. Even I turn off the fedora flatpaks immediately on new systems. I've never seen a single fedora flatpak that worked better than its flathub counterpart, but I've seen the inverse.
The way I see it, the fedora flatpaks are a testing ground for RH flatpaks. When RH offers flatpaks as part of their product, they need to be under RH control for them to be able to properly manage the lifecycle, security and provide support. From that point of view, not relying on flathub makes a lot of sense.
None of that is a concern for fedora, though! I'm struggling to see what the value proposition is supposed to be here for our users. What do fedora flatpaks offer over flathub?
I've never seen a single fedora flatpak that worked better than its flathub counterpart, but I've seen the inverse.
For me it's the Firefox Fedora Flatpak (that I use daily) which works better (at least based on my testing few months ago).
I'm struggling to see what the value proposition is supposed to be here for our users. What do fedora flatpaks offer over flathub?
We need Fedora Flatpaks so Silverblue or Kionite can come up with applications presinstalled as Flatpaks - we don't want them to be part of the base image and we can't use Flatpaks from Flathub.
Fair point, but that's very much an outlier given that RH wants to ship a Firefox Flatpak.
As someone who wants to see flatpak succeed, I think getting flatpaks pre-installed on a bunch of distros would be a big win. If we can't use flatpaks from flathub, then neither can other distros. That also means that they all have to start building their own flatpaks (or reuse the fedora flatpaks, but I don't see that happening).
That's not good and it doesn't scale. We should instead figure out how we can make it possible to ship the flatpaks from flathub instead. I think for the most part it's legal issues? We could maybe work with flathub to offer branches which will get cleared by legal.
To me the issue are apps that are available in both fedora-flatpaks repo and on flathub.
I don't think the fedora-flatpak ones will ever be as well crafted and well tested as their upstream-made-flathub counterpart.
But I do see value on keeping a fedora-flatpak repo for things which upstream is not distributing over flathub. Also, for core apps that are pre-installed that should follow the support cycle of fedora/fedora-runtime.
I don't think this is about choosing one over the other, but making both work together the way that is best for our users.
But also Workstation too: https://pagure.io/fedora-workstation/issue/269
For now I think it's safe to assume Fedora will want to control its preinstalled apps. It's worth debating this, but I'd say not here, since it doesn't really affect how we decide to handle precedence in GNOME Software.
I work for RH on flatpak. Even I turn off the fedora flatpaks immediately on new systems. I've never seen a single fedora flatpak that worked better than its flathub counterpart, but I've seen the inverse. The way I see it, the fedora flatpaks are a testing ground for RH flatpaks. When RH offers flatpaks as part of their product, they need to be under RH control for them to be able to properly manage the lifecycle, security and provide support. From that point of view, not relying on flathub makes a lot of sense. None of that is a concern for fedora, though! I'm struggling to see what the value proposition is supposed to be here for our users. What do fedora flatpaks offer over flathub?
For me, they offer relative confidence that they've been built in a somewhat-secure-ish and reproducible-ish build environment, with fully F/OSS inputs. I can't say I have any trust that that's the case for anything in Flathub.
All builds occuring on Flathub are built offline, and have the checksums of their runtime included in the resulting manifest.
On Wed, Jan 22, 2025, 10:20 AM Adam Williamson pagure@pagure.io wrote:
adamwill added a new comment to an issue you are following: `` I work for RH on flatpak. Even I turn off the fedora flatpaks immediately on new systems. I've never seen a single fedora flatpak that worked better than its flathub counterpart, but I've seen the inverse. The way I see it, the fedora flatpaks are a testing ground for RH flatpaks. When RH offers flatpaks as part of their product, they need to be under RH control for them to be able to properly manage the lifecycle, security and provide support. From that point of view, not relying on flathub makes a lot of sense. None of that is a concern for fedora, though! I'm struggling to see what the value proposition is supposed to be here for our users. What do fedora flatpaks offer over flathub? For me, they offer relative confidence that they've been built in a somewhat-secure-ish and reproducible-ish build system, with fully F/OSS inputs. I can't say I have any trust that that's the case for anything in Flathub. `` To reply, visit the link below or just reply to this email https://pagure.io/fedora-workstation/issue/463
adamwill added a new comment to an issue you are following: ``
For me, they offer relative confidence that they've been built in a somewhat-secure-ish and reproducible-ish build system, with fully F/OSS inputs. I can't say I have any trust that that's the case for anything in Flathub. ``
To reply, visit the link below or just reply to this email https://pagure.io/fedora-workstation/issue/463
IMO, the litmus test should be
flatpak install ...
after the user has already gone through https://flathub.org/setup/Fedora
If the package being installed comes from Fedora Flatpaks, that's unexpected behaviour from a user POV.
TL;DR: Users expect Flathub to be the default. Fedora should respect that.
Insufficient QA is a more fundamental problem than the choice of remote. Remote-agnosticism is an explicit design goal of Flatpak (see "Decentralized by design"). No remote is "blessed".
So far, this thread has identified several examples of apps (most notably OBS studio) whose Flathub distributions received better QA. It does not follow that Flathub flatpaks generally have better QA than Fedora flatpaks. The "verified" status is likely a better predictor of quality than the choice of remote since it indicates what the app developer has personally tested. For apps lacking any sort of endorsement from the upstream developer, there is no inherent reason to prefer one channel over another.
I'm on team "get rid of Fedora Flatpaks entirely".
I've added this to the agenda for next week's Working Group meeting (Tuesday 10 AM EST in Google Meet, open to public).
Metadata Update from @catanzaro: - Issue untagged with: meeting-request - Issue tagged with: meeting
IMO, Fedora Flatpaks can be of "minor quality" than upstream flatpaks because they don't provide full functionality by unbundling non-FOSS things that upstream bundle. But if we take this as a reason for taking down Fedora flatpaks and prioritize FlatHub, frankly we can just stop pretending to unbundle things or license check RPMs too...
Is there a way to list Flatpaks in GNOME Software / KDE Discover in a way that is clearly specified that there are multiple alternative install sources, that Fedora flatpak may have stripped out some functionality due to licensing/binary blobs and that bugs for Fedora flatpaks should not be issued on upstream trackers?
You can not use upstream branding if it doesn't match the upstream product, as one solution. There are projects that require this, as a legal means of preventing users from getting the two mixed up (see the Inochi2D COPR packages).
I'd say these kind of project are not FOSS, so those doesn't belong to Fedora. I can build FOSS any way I like and still use upstream name, there's no "branding" in FOSS. I can also apply patches to upstream sources to make them build in Fedora and call the final product the same as upstream. In fact, I package several RPMs with missing functionality because upstream uses pre-built blobs or relies on codecs which are not admitted in Fedora and yet the final package is named the same as upstream.
What it should be clear to the final user is that any bug should be filed against Fedora package, not upstream, then it's up to the Fedora package maintainer to relay the bug to upstream if they think it's not a packaging bug.
Oh, and I'd say, an additional solution to those proposed: drop Flathub as pre installed install source in Fedora, so there will be no confusion on whether the installed flatpak come from...
The code you have access to is all there, free to modify as you see fit. Branding is not code. Do not get the two confused. You do not get to mangle a project's name just to satisfy your ego.
Read the license. Understand it.
Personal attacks to me will not add anything to your point.
The branding a project uses does not necessarily follow the same license the code does. Firefox is one great example - would you like to remove it from Fedora because they control their branding? The only reason Fedora ships it is because Mozilla gave permission to, under the Firefox name.
Please get yourself out of the pretzel you have yourself in, and realize that reality can't be as you want it.
On Wed, Jan 29, 2025, 12:50 AM Mattia Verga pagure@pagure.io wrote:
mattia added a new comment to an issue you are following: `` The code you have access to is all there, free to modify as you see fit. Branding is not code. Do not get the two confused. You do not get to mangle a project's name just to satisfy your ego. Read the license. Understand it. Personal attacks to me will not add anything to your point. `` To reply, visit the link below or just reply to this email https://pagure.io/fedora-workstation/issue/463
mattia added a new comment to an issue you are following: ``
Personal attacks to me will not add anything to your point. ``
It's quite well established that FOSS projects control their brand and that distros will need to rebrand if required by upstream trademark guidelines. Historically, this is very uncommon because this causes annoyance and confusion to users, e.g. Debian users having access to "Iceweasel" but not "Firefox."
I don't think this is very relevant to the current discussion.
Why don't we just take bit and pieces of what catanzaro mentioned in "alternative 2" to get the best of both worlds and do the following:
Fedora Flatpaks > Fedora RPMs > Flathub by default whilst only having the "GNOME core applications to implement https://pagure.io/fedora-workstation/issue/269" hosted in the Fedora Flatpak repo so most packages will go to the Fedora RPM and then to Flathub.
And then to top it all off, make it configurable so people can change the order between whether Flathub or the Fedora RPM is prioritised first if the package is not hosted in the Fedora Flatpak repo which should only host "GNOME core applications to implement https://pagure.io/fedora-workstation/issue/269"
I feel like this way will make the most people happy.
This change should also be reflected to the KDE Spin (Fedora Workstation KDE in the future)
Adding Flathub and disabling Fedora flatpaks i one of the first things i do when installing fedora, i don't see why i would want to use a fedora specific flatpak, Flathub packages are by default more tested since they are shared between all distros using flathub, i get what Fedora flatpaks is trying to do, but in my opinion it's simply a waste of ressources, and a source of confusion for people that are expecting to get the same thing as the Flathub repo.
This entire discussion is unnecessary for Fedora KDE, since Plasma Discover already gives users the flexibility to choose their own repo priorities.
Also, Fedora KDE isn't getting named Workstation KDE
It still stands that users probably wouldn't know to change their repo priorities, unless they're very technical. Expecting them to do so hinders adoption of the Linux desktop.
Just have Flathub Verified at the highest priority. Those will always be superior to Fedora Flatpaks, both in terms of functionality and upstream support.
The priority for enabling Flathub over Fedora's Flatpak repository on Fedora Silverblue should be clear: Flathub offers a broader range of applications, including essential media codecs that many users need. It’s important to recognize that not everyone is a tech enthusiast; even seasoned Linux users may not be fully aware of the existence of Fedora's Flatpak repo or its codec limitations.
Consider a beginner who installs Fedora Silverblue, adds Flathub, and attempts to use Kdenlive or various media players. When they discover they can't edit videos or play media files due to Fedora's restrictive codec policies, they may quickly become frustrated and view Linux as ineffective for their needs. This frustrating experience can deter potential users from adopting Linux altogether.
By prioritizing Flathub (If enabled), we can provide users with a more comprehensive and user-friendly experience right from the start. This approach not only addresses the immediate needs of new users but also fosters greater acceptance and understanding of Linux as a viable operating system for everyone.
Individuals who opt not to enable third-party software will still be able to utilize Fedora flatpaks. Therefore, I believe this approach is the most suitable for everyone and honors user choice.
P.S.: a linux youtuber Brodie Robertson just released a video an hour ago with thousands of views of this issue and everyone seems to be in favor of fedora flatpak disappearing completely so it's not at all crazy what I'm proposing.
This is a default change proposal, it doesn't matter if the user can change stuff, because they always can, it's Linux. Defaults matter.
As an end-user, I always end up disabling Fedora Flatpaks, I've just not have had a great experience of them, a lot of them seem to be too permissive when it comes to permissions (look at Firefox! I thought we wanted proper sandboxing, but nah, let's give read access access to /home (when it uses portals usually), have it have access to the native package's .mozilla folder instead of putting it in .var/app, and still break the Firefox sandbox because it's a Flatpak!), Fedora Flatpaks should never package verified packages on Flathub. You're not gonna package it better than the official developers, or be more trustworthy or secure.
I'm struggling to put it into words, but I think the main idea of what I want to say is:
Fedora Flatpaks aren't usable for the average end user of a Linux desktop. They're better suited for corporate environments where they're not really allowed to have programs managed by a third party inside of their environment.
If Fedora is going to keep Fedora Flatpaks, please only promote it for non-average-users, please.... Nobody using their desktop to play video games is going to want Fedora Flatpaks. Sysadmins within a company probably will. Use Fedora Flatpaks where they matter, and stop trying to push them where they have no use.
Back in the days when mp3 was still covered by patents, many Fedora first time users complained that they cannot play their music files out of the box. Yet, we didn't ship third party repositories to "fix" the user experience. I believe we're in the same situation and it's my opinion that Fedora shouldn't change it's philosophy of promoting free software by shipping free solutions only.
As an example and as a package maintainer, I wanted to package and make a flatpak of a astronomical 3d simulator, but I've discovered that, while the code it's open source, it carries a lot of textures with a lot of unknown or not admitted licenses. I could have said "who cares, let's ship it in Flathub", but I chose to get in touch with upstream and raise the problem. They're now working on replacing those textures to deliver a fully free software that can be included in Fedora and other distributions may benefit too.
Changing Fedora to ship by default Flathub flatpaks will only demote any package maintainers and upstream maintainers to fix these kind of problems. Anyway, I hope such a change will be discussed with a broader audience in the devel mailing list and a change proposal should be made public.
I feel like we should either get rid of the fedora flatpak repo entirely or have it just host "GNOME core applications to implement https://pagure.io/fedora-workstation/issue/269" so most packages are installed by the Fedora RPM or Flathub with it going Fedora RPM > Flathub as default whilst giving the user the option to change the which is prioritized first.
Back in the days when mp3 was still covered by patents, many Fedora first time users complained that they cannot play their music files out of the box. Yet, we didn't ship third party repositories to "fix" the user experience. I believe we're in the same situation and it's my opinion that Fedora shouldn't change it's philosophy of promoting free software by shipping free solutions only. As an example and as a package maintainer, I wanted to package and make a flatpak of a astronomical 3d simulator, but I've discovered that, while the code it's open source, it carries a lot of textures with a lot of unknown or not admitted licenses. I could have said "who cares, let's ship it in Flathub", but I chose to get in touch with upstream and raise the problem. They're now working on replacing those textures to deliver a fully free software that can be included in Fedora and other distributions may benefit too. Changing Fedora to ship by default Flathub flatpaks will only demote any package maintainers and upstream maintainers to fix these kind of problems. Anyway, I hope such a change will be discussed with a broader audience in the devel mailing list and a change proposal should be made public.
I understand your perspective and support the ideals of Fedora, but I believe it is crucial to approach these discussions with careful consideration. If the community isn't aware of the issues at stake, the fight to uphold the principles of free software loses its significance. We must remember that if we don't address users' needs, we risk them being drawn to distributions with lower ideals, such as Ubuntu.
In this instance, we're not talking about including codecs by default or anything like that; rather, if a user consciously chooses to enable third-party repositories, Flathub should take precedence over Fedora’s Flatpaks. It seems somewhat ridiculous that the user's choice is not respected. I would bet that more than 90% of Fedora users, especially those on Silverblue, utilize Flathub. Forcing decisions and disregarding users' wishes can only harm the distribution and the original cause we support, much like how Ubuntu installs a snap when a user installs a .deb, tricking novice users who may not understand what’s happening, and even intermediate users, all while increasing fragmentation and confusion.
Over time, users may come to appreciate the importance of these principles, but we need to make that journey easier, not obstruct it. We should also acknowledge that, aside from a few enthusiasts like us, very few people understand what Fedora Flatpak is; they just see that their apps aren’t functioning as expected, which can frustrate them and potentially cause irreparable damage to Fedora. With the rise of competing distributions, Fedora is extremely important to me, and I don’t want it to fall behind due to an absurd decision, especially when users might be misled into opting for distributions that promote worse ideals. This is a turning point, and every misstep counts.
<img alt="Screenshot_From_2025-02-03_13-10-11.png" src="/fedora-workstation/issue/raw/files/f07375c5c1a4ae9002bfb70a437d26b8ab96f2118506b0c06d34b9899a8bab39-Screenshot_From_2025-02-03_13-10-11.png" />
Source: https://www.youtube.com/watch?v=GIqhJLbOaOk
In this instance, we're not talking about including codecs by default or anything like that; rather, if a user consciously chooses to enable third-party repositories, Flathub should take precedence over Fedora’s Flatpaks. It seems somewhat ridiculous that the user's choice is not respected.
If the proposal is to continue shipping out of the box Fedora RPM + Fedora Flatpak and then, if a user choose to enable Flathub as third party, make it priority I have no objection, assuming there's some explanation to warn what the user is doing and it's not just a switch without any explanation. In this case it might also be more clear to completely switch, for example saying to the user "if you choose this, you'll disable Fedora Flatpak and enable Flathub as flatpak provider".
But it was my understanding that the proposal is to ship Flathub out of the box over Fedora flatpaks, and on that I disagree.
I'm speaking for myself, but I would be mostly happy if you went ahead with that. The issue on Fedora Silverblue, where default applications from Fedora Flathub lack codec support, would still persist. However, users would at least have the freedom to install an alternative after enabling third-party repositories.
This may seem trivial, but on Silverblue, it's a significant issue. Still, it's better than nothing, and you have my vote for that proposal at the very least.
One result of the meeting I think I would like to mention is a packaging priority more like so, as someone (an end user, actually) brought up that the Steam Flatpak has tendencies to be a fair bit worse than native (which is a known problem, but we can't do much without Valve's help):
And I requested that https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2577 be reopened, so more technical users can set their system up more to their liking without poking around in dconf.
We had a long discussion about this at today's Workstation Working Group meeting (minutes), but didn't reach any final conclusions yet. We do seem to have consensus on a couple important points:
There are various ways we could fix this, and we haven't agreed on what to do yet. Some more points from our meeting:
Some of my own additional thoughts that I didn't present during the meeting:
We require further discussion to agree on a priority list for a change proposal. Our current priority list is: Fedora Flatpak > Fedora RPM > Flathub. There are many possible resolutions. We did not yet debate which resolution would be best:
If you managed to read this far, this is a good place to debate all of the above. :)
Both Flathub and Fedora Flatpak applications are much safer than Fedora RPMs, but only if they do not use sandbox holes.
Let's not forget the notable exception of Chromium and Chromium-derived applications, whose Flathub distributions rely on community modifications of the Chromium sandbox which have not yet undergone upstream review.
Sure, but Chrome is an unusual exception. (And Fedora's Chromium package is probably not what users want anyway.)
Maybe I've overcomplicated this discussion. Instead of trying to sort a complicated precedence scheme here, we could leave that for another issue report to solve another day, and simply remove Fedora Flatpaks from the sources. Then this issue is resolved (until we are ready to preinstall Flatpaks, which could use a separate repo).
Sure, but Chrome is an unusual exception. (And Fedora's Chromium package is probably not what users want anyway.) We require further discussion to agree on a priority list for a change proposal. Our current priority list is: Fedora Flatpak > Fedora RPM > Flathub. There are many possible resolutions. We did not yet debate which resolution would be best: Maybe I've overcomplicated this discussion. Instead of trying to sort a complicated precedence scheme here, we could leave that for another issue report to solve another day, and simply remove Fedora Flatpaks from the sources. Then this issue is resolved (until we are ready to preinstall Flatpaks, which could use a separate repo).
This is not going to fly. I certainly would not support it. The simple thing to do here is to get the UI for the source sorting in place, and then go from there.
I support the idea of Fedora's Flatpak remote being far more selective in what gets packaged there, perhaps as strict as packaging only apps that are preinstalled in the atomic releases.
AFAIK this was our initial goal with Fedora Flatpaks. I am not involved with the project recently, but I was when it started. I gave a talk about it back then in Flock 2018. The idea back then was never to compete with Flathub. I think we failed at setting clear goals for the project, which caused people with different goals to fill up the space with their own goals (apparently packaging everything under the sun).
From where we stand now, I think a good approach could be to introduce a new repo for the core/base-pre-installed flatpaks which we want to ship pre-installed in Fedora, and drop the existing Fedora Flatpaks repo altogether.
I'm a Fedora Silverblue user, and I proposed prioritizing Flathub when users enable third-party repositories. This makes sense because users are consciously opting in, and without Flathub, many apps lack essential codecs—my main concern with Fedora Flatpaks.
Steam works well for me, and I use it actively, but you need to layer steam-devices to get the necessary udev rules for joystick compatibility, which is crucial. I also layer ffmpegthumbnailer and libavcodec-freeworld to enable video thumbnails. I don’t understand why steam-devices isn’t included in the base image by default since it only provides udev rules.
steam-devices
ffmpegthumbnailer
libavcodec-freeworld
Additionally, I believe enabling third-party software should automatically install these codec-related packages or at least offer an option in the prompt to do so. This would make Silverblue far more user-friendly and accessible.
We can specify the CollectionID (i.e. where we want to install from) for pre-installed apps. From that perspective the priority discussed in this issue doesn't matter.
If that is still the goal, then I think Flathub > Fedora Flatpak > Fedora RPM, and pre-installing from Fedora Flatpak is the best choice here.
OBS Studio is not a particularly good example because in addition to being unsandboxed, it also notably depends on an EOL runtime that no longer receives security updates. In this particular case, I would actually prefer to install the Fedora RPM version of this app.
This particular comment feels a bit reductive. The runtime we haven't updated is Qt itself, the reasons for which are well documented and a particular pain point for us. Qt wasn't updated in the OBS Studio Flathub package because we test all new versions before blindly upgrading, and found there were regressions. The regressions weren't fixed until recently, and we evaluate dependency bumps with each release cycle. Surely we all as developers and maintainers understand that updating to the latest dependency versions available is not always the best solution, especially when those updates introduce breaking changes. We made the choice to have a functional application, report the bugs upstream, and update the dependency once they have been fixed. We have found this strategy works very well for us.
I understand this comment is very unlikely to gain any support, but primarily as a "casual" end user of Linux, I find the distribution of completely different packaging methods in the same chain to be very strange. I would personally never want an RPM mixed with a Flatpak mixed with an AppImage or whatever other packaging method. As far as I know, most other platforms keep these install methods separate, and combining them is odd to me. While I understand the point is likely to reduce user friction, and that they shouldn't have to care how something is packaged, that is a very idealistic viewpoint that in my experience does not match reality. Applications will behave differently in a Flatpak vs an RPM vs X other packaging method, just by nature of how those packaging methods work. This difference is not unique to Fedora. Even our own, highly tested and vetted Flatpak has differences and some limitations over a "native" package. Just my 2 cents, however, so no further discussion here is required.
All of that said, I'd like to throw in my support for the method of Verified Flathub as priority when installing a Flatpak by default, as well as making it easier to change the priority if a user wishes. It is my personal opinion that this is a good compromise to what Fedora is attempting to accomplish, and maintaining user trust and choice.
As a final talking point, we are an upstream application, and have been given the impression that our reports are largely falling on deaf ears and being dismissed because of reasons that don't seem to be fully understood by Fedora themselves. I have said this before, but I will say again it should not be upstream's responsibility to track and report on downstream packaging issues, and the fact that we have and it's been ignored has been frustrating. I still don't have a good understanding on why Fedora is so adamant about repackaging and redistributing Flatpaks wholesale without proper testing or validation.
Yselkowitz currently packages, at last count I had checked a week or so ago, 1378 packages. In what world is a single person able to maintain, test, and support, that many packages and applications? The entire initiative seems poorly planned, badly implemented, and is largely unsustainable. It might be best to take a step back and really think about what Fedora is trying to accomplish long-term here, instead of rushing to the finish line. It sounds like these conversations are starting to be taken seriously, and we're thankful for the transparency on them. I hope they continue to move in the right direction and take further steps to ease the pain points until long term solutions can be implemented.
We discussed this again today for the entire duration of today's Working Group meeting, but didn't reach any conclusions.
Honestly this line of argumentation gives considerable ammunition to proponents of Fedora Flatpaks. One of the arguments in favor of Fedora Flatpaks is that Flathub maintainers are sometimes just bad at maintaining their packages, and, well... suffice to say I'm quite surprised we need to debate whether it's acceptable to use an EOL runtime that no longer receives security updates. If OBS Studio is truly unable to keep up with KDE runtime updates, there are better options:
I suppose that if OBS Studio only receives screencast input from the user's own desktop, then the security risk is probably zero (unlike, say, a video player or editor application, which is very high risk). But still, on principle, keeping up with runtime updates is one of the most basic expectations of a maintainer, and I suspect it's a sign there may be other problems as well.
My counter-proposal is to prefer Probably Safe Flathub. That would exclude applications with --filesystem= or --talk-name= permissions, or EOL runtimes, etc. It can be an carrot incentive for application developers to contribute to xdg-desktop-portal development, but also wouldn't penalize applications relative to the status quo where Flathub is currently always the lowest priority.
--filesystem=
--talk-name=
I'm also fine with requiring Verified status, but I don't care as much about that as I do about the Probably Safe status. The sandboxing allows us to have a much greater degree of trust that it's hard to exploit the app even if there are bugs.
I've asked the Flatpak SIG to respond to that issue report.
That said, I suggest also reporting an issue for the crash we've now had two developers check the OBS Studio Fedora Flatpak and neither were able to reproduce any crashes. The packagers are surely going to need a stack trace.
For some reason I only see 763 packages, half as many, but that's still quite a lot.
I agree with this argument. Fedora Flatpaks have had their chance but have not been successful. I'd say it's time to move on. Based on our discussion so far, I think Workstation Working Group does not want to tell Fedora developers to stop packaging things, but perhaps we can exclude the Fedora Flatpak repo from the default software sources and require that users enable it manually if they really want it. I expect there would be very few users, though. We can create a separate Fedora Flatpak repo for Fedora Workstation preinstalled applications only, where we have legitimate strategic need for Fedora Flatpaks, and otherwise stop trying to package the world.
Is the long term expectation that all Fedora packagers are retiring, and all (or most all) apps will be available from flathub as flatpaks (minus core apps which are Fedora flatpaks)?
Is there a way Fedora flatpaks could be mirrored on flathub? i.e. could Fedora flatpaks be the best in class and also happen to get used in flathub? And let flathub figure out whose flatpak they'll promote?
What about asking Fedora packagers to use their judgement, per app, what to offer? And in what order? Or put another way, why are we second guessing the app packagers?
I vastly prefer and trust someone in the Fedora community deciding how to package an app. That includes whether the only offering is a flathub flatpak, fedora flatpak, RPM. Or any combination thereof. I'm not even certain about having multiple fallbacks, and therefore not sure about the need for UI for this.
e.g. if the packager says GNUCash should come from flathub, and there shouldn't even be a fallback to the Fedora flathub - then so be it. I would need to manually install the app manually from flathub or enable 3rd party repo in GNOME Software, so it shows up as an option. If the packager says flathub is better and Fedora flatpak is fine, then I'd get the Fedora flatpak if 3rd party repo isn't enabled. But I'd get flathub flatpak if 3rd party is enabled. Not two visible choices.
If it turns out Fedora packagers want to stick with RPM for 50% of the apps I use, then I guess I'm using RPMs. And I don't mind. That's how I feel about it.
I expect to get many more options when I enable 3rd party repos. What I don't expect is that I'm now getting flathub flatpaks instead of Fedora sourced binaries just by policy making it the default. I'd feel better about it if it's intentional. Per app.
If I think the quality level of an app is subpar then I'm confident Fedora's packager for that app would say the same thing, and would know "the flathub flatpak is better, use that". So why not permit them a mechanism to make these decisions?
I wasn't going to reply to this, but the audacity of implying we're bad maintainers after trying to extend an explanation to things you very clearly don't understand, and now I see don't care to understand, is just a bit much. Not a good look for you to insult our community and developers who spend an immense amount of time and effort to keep things updated, tested, and stable. Guess all the work that our community has done to move away from the overly-aggressive KDE runtime deprecations means nothing because we opted to do things right, instead of fast.
There’s a big difference between defending free software and prioritizing security, and unnecessarily creating fragmentation and confusion among users who aren’t developers but still know exactly what they’re doing. When it comes to a specific package like OBS Studio, I’d much rather see a clear warning in the software center indicating that it uses outdated libraries than have a sort of “digital babysitter” deciding what I can or can’t install, modifying apps from their original source, and distributing their own versions without proper testing or adequate support for codecs or filesystems.
For applications like OBS, web browsers, or video editors, this is critical. How am I supposed to open files from other drives if essential permissions or integrations are missing?
Then there’s the elephant in the room: Fedora Atomic Desktop. If a user consciously clicks to “enable third-party software” after installation, it should be clear that they’re choosing Flathub as their main source. That should be the priority, out of respect for the user’s decision—just like in any other distro.
Why treat us as if we’re incapable of making informed decisions? If the real concern is user safety, then why not respect the Flathub option when enabling third-party support? This would prevent absurd situations where an average user gets confused because their video editor doesn’t show thumbnails, or their favorite app can’t access a simple file from a USB stick.
Regarding the maintenance of EOL runtimes: I understand the security risks, but the solution shouldn’t be to impose global restrictions. I’d rather have a fully functional piece of software with clear warnings about potential vulnerabilities than a broken or limited version due to arbitrary decisions. The idea of having to “trust” that someone else decides what version is safe without consulting the community or end users is, honestly, counterproductive.
If the goal is truly to support Fedora’s ecosystem in a sustainable way, efforts should be focused on improving communication with upstream maintainers, optimizing testing processes, and most importantly, respecting user autonomy. Fedora has always been a distro for people who want to learn, experiment, and have control—not for those who need someone else to decide for them.
Please stop turning Fedora into a frustrating experience for advanced users, and trust that we know what we’re doing.
I won't mince words: allowing the runtime to go EOL is unacceptable and indicates terrible maintainership. I'm glad you're working on fixing it, but this situation makes it much harder to argue that Fedora Flatpaks are not adding significant value relative to Flathub.
Moreover, the fact that Flathub allows the application to remain listed with an EOL runtime indicates insufficient quality control on Flathub's part. Is there no procedure to delist applications with stale runtimes? I wonder whether Flathub's OBS Studio is unusually bad, or if this is representative of poor quality control on Flathub in general?
(That said, it sure seems like it would be much easier for Flathub to improve its packaging requirements than for us to build hundreds of Fedora Flatpaks to compete with Flathub Flatpaks.)
Well that's the status quo, but we are receiving a large number of complaints, so I'd say it's not working. Only a couple Fedora developers have said they prefer Fedora Flatpaks rather than Flathub. Most Fedora users want Flathub Flatpaks, not Fedora Flatpaks.
That's sort of my expectation, but with pretty huge caveats:
So I don't really see Fedora RPMs fully going away ever. But yes, surely most all apps are already available from Flathub?
I understand the security risks, but the solution shouldn’t be to impose global restrictions. I’d rather have a fully functional piece of software with clear warnings about potential vulnerabilities than a broken or limited version due to arbitrary decisions. The idea of having to “trust” that someone else decides what version is safe without consulting the community or end users is, honestly, counterproductive.
It's your computer and users should always have ultimate say in what they do or do not install, but Fedora also has a duty to users to warn when something does not look right. The current safety state UI is easily ignored and clearly insufficient. The safety guidelines are not arbitrary; we should develop plan to make it gradually harder and scarier to install software that is unable to achieve a Probably Safe rating, and eventually delist it and require sideloading. This notably includes all Fedora RPMs. (But I think we're getting a little off topic now; we can probably discuss this elsewhere?)
True, based on the limited number of users that replied here (which are mostly those who raised the issue at first). As I said before, I'd expect a different outcome of numbers if a Change Proposal is filed.
Users simply don’t know what the issue is—they just see that Fedora isn’t working properly, get frustrated, and either abandon it or waste hours searching for solutions.
Claiming that only a few people are unhappy with this issue based solely on the comments here is a fallacy. This is a common mistake among many developers and maintainers—they assume that everyone is a tech-savvy “nerd” who knows exactly what everything is, completely ignoring the fact that there are many users who don’t even know what Fedora Flatpaks are.
Are our voices here not enough? Maybe 380 comments, almost 2,000 likes, and over 22,000 views on the video that exposed this issue https://www.youtube.com/watch?v=GIqhJLbOaOk are enough to be taken seriously?
The matter is simple: Either you listen to the users and fix this ridiculous issue—like properly setting the repository priority when someone consciously enables third-party repositories in Fedora—or you’ll start losing users to other distros with much lower standards, like Ubuntu with its Snaps.
In case you don’t feel like checking it out, here are the first few comments to give you an idea.
<img alt="Screenshot_From_2025-02-12_19-49-00.png" src="/fedora-workstation/issue/raw/files/ed09b5e83d56b49ba262a241a2ef2affe82012bf57a097cf4a1fd366d1514e91-Screenshot_From_2025-02-12_19-49-00.png" />
We can specify the CollectionID (i.e. where we want to install from) for pre-installed apps. From that perspective the priority discussed in this issue doesn't matter. If that is still the goal, then I think Flathub > Fedora Flatpak > Fedora RPM, and pre-installing from Fedora Flatpak is the best choice here.
Possibly, but there is a downside: whether you get Flathub or Fedora Flatpak now depends on whether you selected Enable third-party repos, so the order matters a lot. Users are still going to wind up installing the Fedora Flatpak, discovering problems, and reporting bugs to upstream.
Since the consensus seems to be that RPMs should be at the end of the priority list, what about decoupling (removing) RPMs from GNOME Software completely?
This might seem to be a step back, but it would make GNOME Software more consistent between Workstation and Silverblue, and support Fedora in its goal to make Flatpaks the primary packaging option.
That would leave RPMs to be a choice of the more advanced users, who seem to prefer the powerful dnf over GNOME Software anyway.
With RPMs missing from GNOME Software, prioritizing package sources becomes easier too: be it Fedora Core -> Flathub Verified (or Probably Safe) -> Fedora Extended -> Flathub Extended or similar.
Removing RPM applications is my long term goal, but I'm not sure how quickly we'll be able to get there.
@fenrirthviti
Guess all the work that our community has done to move away from the overly-aggressive KDE runtime deprecations means nothing because we opted to do things right, instead of fast.
If I understand the linked PR correctly, it's switching the OBS Flatpak to ship its own copy of Qt rather than using the one from the runtime.
Do you have a process for quickly applying security updates, as well as staying on versions that have security support from upstream?
According to https://endoflife.date/qt, "There is a new minor release approximately every six months, which is supported with bug and security fixes until the next minor release." (Commercial users get better support.) Perhaps there's some detail I'm missing, but it sounds like you're on a version that is considered EOL not just by whoever is shipping the KDE Flatpak runtime, but by Qt upstream.
If so, then addressing the situation by switching from the runtime to a bundling approach is not "do[ing] things right". To the contrary, it just sweeps the issue under the rug without solving it. Flatpak will no longer know to complain about the missing security support, but the support will still be missing.
(I do not claim that Fedora's approach is any more right. This is a hard problem. To a large extent, it is Qt upstream that is deliberately making life hard for its open source users by not making LTS releases available to them. But I digress.)
That is, with all the respect, a very bad idea and would damage the Fedora Workstation as a whole.
@asciiwolf: [decoupling (removing) RPMs from GNOME Software completely] is, with all the respect, a very bad idea and would damage the Fedora Workstation as a whole.
I'm certain there are downsides too, that would need to be mitigated. Automatic updates is one of them.
I'm seeing all kinds of issues reported by users on Fedora Discussion (Ask Fedora), when combining GNOME Software with dnf, which only got aggravated since the introduction of dnf5 with F41, while PackageKit still uses dnf4.
dnf5
dnf4
But this is another discussion topic, I wouldn't want to take up the space here.
If this is what some stubborn individuals wanted, well, here you have it—a LAWSUIT from a group of developers against Fedora for misleading users and undermining upstream maintainers. Still think no one is paying attention?
This video (https://youtu.be/dJJvq3dpylM) was just released yesterday and already has thousands of views, once again highlighting this ongoing issue.
If you continue refusing to respect user choice—despite them explicitly enabling third-party software—and insist on not making Flathub the default, then these are the inevitable consequences. Congratulations on driving users away from Fedora and straight into distros like Ubuntu. If that was your goal, you’re succeeding brilliantly.
Start acting like responsible adults instead of treating users as tech-savvy nerds who are expected to know about Fedora Flatpak and blindly accept when an arbitrary decision forces them into using a crippled, unofficial package with basic functionality limitations.
There are two issues here: the choice of default channel for an application (flatpak remotes, RPMs) and branding requirements for downstream packagers. Should RPMs be also labeled as "unofficial" if the upstream publishes a build on Flathub?
All packages should be marked as unofficial unless upstream approves them themselves.
On Fri, Feb 14, 2025, 7:11 AM Casey Jao pagure@pagure.io wrote:
casey128 added a new comment to an issue you are following: There are two issues here: the choice of default channel for an application (flatpak remotes, RPMs) and branding requirements for downstream packagers. Should RPMs be also labeled as "unofficial" if the upstream publishes a build on Flathub? To reply, visit the link below or just reply to this email https://pagure.io/fedora-workstation/issue/463
casey128 added a new comment to an issue you are following: There are two issues here: the choice of default channel for an application (flatpak remotes, RPMs) and branding requirements for downstream packagers. Should RPMs be also labeled as "unofficial" if the upstream publishes a build on Flathub?
Since the consensus seems to be that RPMs should be at the end of the priority list, what about decoupling (removing) RPMs from GNOME Software completely? This might seem to be a step back, but it would make GNOME Software more consistent between Workstation and Silverblue, and support Fedora in its goal to make Flatpaks the primary packaging option. That would leave RPMs to be a choice of the more advanced users, who seem to prefer the powerful dnf over GNOME Software anyway. With RPMs missing from GNOME Software, prioritizing package sources becomes easier too: be it Fedora Core -> Flathub Verified (or Probably Safe) -> Fedora Extended -> Flathub Extended or similar.
I really wish you would reconsider this idea of dropping RPMs now. For reference, I am the end user Oro mentioned here https://pagure.io/fedora-workstation/issue/463#comment-953937, and I really do wish to keep being able to manage RPMs from GNOME software. I'm not a power use of Fedora particularly, but I still need to use a lot of RPMs.
While I Like using DNF, being able to install and manage not just Steam, but other RPMs like my Nvidia GPU Drivers, GNOME Boxes and IDEs that can't work as a Flatpak, plus being able to do system updates from GNOME software. It makes fedora feel much smoother to use than the plethora of other distros shipping GNOME that dont do this.
I love flatpak so much, so much I am only targetting Flatpak with the software I write. However, I really wish to continue to be able to manage RPMs until there are better methods of managing software updates, GPU drivers and such.
I understand this is just a proposal and not concrete yet, and I have nothing but respect for maintainers of both RPMs and Flatpaks, but I don't really understand why dropping RPMs from GNOME software would do to fix the bad state of Fedora Flatpaks at the moment.
We can specify the CollectionID (i.e. where we want to install from) for pre-installed apps. From that perspective the priority discussed in this issue doesn't matter. If that is still the goal, then I think Flathub > Fedora Flatpak > Fedora RPM, and pre-installing from Fedora Flatpak is the best choice here. Possibly, but there is a downside: whether you get Flathub or Fedora Flatpak now depends on whether you selected Enable third-party repos, so the order matters a lot. Users are still going to wind up installing the Fedora Flatpak, discovering problems, and reporting bugs to upstream.
If Fedora Flatpak only serves preinstalled GNOME apps, that won't be an issue for anyone other than GNOME, who have a good relationship with Fedora as well as the bandwidth to discuss any issues if they arise.
But even if Fedora wants to run a "Librehub", I don't think there's any use in competing with Flathub if 1. the upstream developer of an app ships it there officially, and 2. the user has chosen the "3rd party repositories please" option - users will instinctively contact upstream, and upstream has agreed to this by choosing to be the Verified maintainer on Flathub. If a user does not want 3rd party repos and would rather have the assurances offered by the Fedora build, they get the Fedora flatpak repo as default instead.
We can have a discussion on what Fedora could/should/shouldn't bother to package as Flatpaks, but the present issue seems solvable if Fedora complies with the user's choice & doesn't try to "hijack" apps without good reason. Which, if the upstream ships their app a certain way & the user prefers their version, any bugs/issues are upstream's problem.
Pursuant to that, maybe instead of the nebulous "Enable 3rd party repos", users are presented with "Choose your preferred way to install apps:" and a radio between "Install apps from Fedora - apps are modified to meet our standards for software freedom, security, and stability. Receive support from Fedora" and "Install apps directly from developer - the official version of apps, unmodified by Fedora. Supported by the app's official developer"
That way users know what's on offer and can make an informed choice.
But in either case, for the present issue, I think if the user chose 3rd party repos, we should be offering Flathub by default for anything other than preinstalled core apps.
@zoeythetranswitch It can make sense when ~90% of GUI apps that are currently part of the Fedora RPM repository will already be available as Fedora Flatpaks or at least on Flathub. And even if this was the case, there are some apps that are very hard to package as Flatpaks yet are very popular among some user groups. And there are also some users that prefer RPMs over Flatpaks for various reasons.
Also, doing this would, in my opinion, make Fedora Workstation not much useful anymore since Silverblue already offers RPM layering using CLI.
Anyway, this discussion is really off-topic here and we should continue it somewhere else.
From @catanzaro:
Just for the avoidance of doubt for people poking in here: this is not happening anytime soon, and we acknowledge it may never happen because users of Fedora Workstation and contributors to Fedora may always want or need to use RPM packaged software.
@plughead I think there's a lot of kinda 'impedance mismatch' going on here between how distros see things and how upstream maintainers see things.
It's important to understand there's a whole distro worldview that has been around for 30 years and that people aren't going to let go of overnight. Fedora, and all Linux distributions, originally exist specifically to package and distribute software written by others. That's kinda the thing we do. So this idea that "oh obviously if you can get it from upstream that's what you want!" which is 'obvious' to (some) upstream maintainers is not so obvious to people who make distributions. It's also not obvious to some users of distributions; when people object to the 'concept' of snaps and flatpaks, a lot of the time, what they're really saying is "I'm comfortable with the model where my distributor builds all my software for me and that's what I want to keep doing".
When you talk to people with a distro mindset it's a bit of a mistake to assume that you can start from a shared principle that "of course software built by upstream is always better!" This isn't what distro people necessarily think. You have to make the case. Some of us have already been pushing the idea that distros should give up trying to package everything in the world for several years, but a lot of people still quite like the traditional distro model, and feel like they're being pushed to give it up. Everyone's sensitive to challenges to their worldview.
The backstory behind why Fedora has this "third party repos" choice puts it in a bit of a different light to how you're reading it. Neither reading is wrong, as I said it's just a kinda 'impedance mismatch'. For much of its existence, Fedora had an explicit policy that blocked anything in Fedora from offering software from "third party" sources. This eventually became a problem when Silverblue and the other atomic variants showed up, so the workstation WG starting pushing against that policy. And there was a lot of pushback. It took a while to get the policy changed to allow any kind of "third party" sources to be offered at all, and requiring explicit consent from the user was a part of that. Requiring Fedora flatpaks to be ahead of Flathub in the precedence was also a requirement from fesco or the council or someone to get one of the various proposals in this area approved, IIRC - there's already been several successive stages of 'loosening' here, at first even offering a full Flathub repo was considered to be going too far, we had a thing called 'filtered Flathub' for a while.
To the traditional distro mindset, "third party" sources are a kind of dark scary force to be avoided at all costs. It's not natural to view this "do you want third party sources?" dialog as a sort of enthusiastic declaration that you LOVE third party sources and want software from them wherever possible. To a distro person, this dialog reads like us telling the user "look, we're WARNING you, okay? don't come complaining to us about all the terrible software you're going to get from these third-party sources! and obviously you still want software from us wherever possible, we're your friendly local distributor! this is just us grudgingly agreeing to give you stuff from elsewhere if you can't get it from us".
Obviously I'm exaggerating here. I'm just trying to illustrate the different mindsets at play, which I think it's kinda important to understand to realize why the current Fedora config is as it is, and why various folks seem to be confused about why not everyone else sees things in the way that is 'obvious' to them.
oh, forgot to mention - the distro mindset wariness against "third party" software isn't blind prejudice, it exists for good reasons. They're just a bit outdated when it comes to flatpaks. Ironically, the reason is pretty similar to the bad experience the obs-studio folks are having that prompted this ticket: historically, one of the biggest sources of problems for Linux distro users was...third-party software. Anyone who put in time doing support for any Linux distro before the 2020s knows this. Third-party packages or non-package installers - including ones from upstreams - frequently caused major problems that then got reported to distros as bugs in the distro. This is the source of the distro mindset's unease with them.
Things used to be that way, but as you yourself mentioned, times have changed. The concerns about third-party software causing issues were valid in the past, but Flatpak has fundamentally changed the landscape. It provides isolation, permissions control, and a consistent runtime, making it a far more reliable option than the "third-party software" problems of the past.
What I’m proposing is simple and reasonable: if a user explicitly enables third-party software, then Flathub should be activated and set as the first priority. How maintainers choose to manage things beyond that is up to them, but this is the expected behavior in virtually every other distro. When users enable third-party support, they expect to have access to third-party apps and codecs—plain and simple.
AFAICS, I'm not sure anyone is really against that. @catanzaro proposed the same thing in the first post in this ticket, and has consistently supported broadly the same change throughout the ticket. He summarized the result of the first meeting about this here and the second meeting here. The second one got messy because of the somewhat unnecessary arguing about Qt EOLs, but even then, it ends with:
"Based on our discussion so far, I think Workstation Working Group does not want to tell Fedora developers to stop packaging things, but perhaps we can exclude the Fedora Flatpak repo from the default software sources and require that users enable it manually if they really want it. I expect there would be very few users, though. We can create a separate Fedora Flatpak repo for Fedora Workstation preinstalled applications only, where we have legitimate strategic need for Fedora Flatpaks, and otherwise stop trying to package the world." If anything, that goes further than your proposal - he's talking about entirely disabling the Fedora flatpak remote by default, not just bumping it down the precedence order.
Possibly this is taking longer than you'd expect, from the outside? I can see a few reasons for that:
This is likely going to get done as a Change proposal, because that's how all the previous changes in this area have been done, and it's an established mechanism which makes sure everyone interested is aware. Proposing a Change requires a bit of drafting, including anticipating various questions/objections that will be raised and preparing explanations to address them. All these annoying detail questions about "well what about Flathub packages that aren't high-quality ones from the upstream app maintainer?" "what about RPMs?" and so on are inevitably going to come up in that process; the workstation WG will want to work all that out and have answers ready ahead of time.
btw, as a side note, it is frustrating that the Workstation WG meets on video and (AFAIK) doesn't record it, so there is no complete recording of what was actually said. While @catanzaro has posted detailed summaries for this issue (which is appreciated!), the official minutes are...uh...uninformative.
This is a big drawback of video meetings, for me. Most Fedora groups still meet via chat, and thus a complete log of everything that was said is available. I frequently find this extremely valuable in cases like the current one. I've found more than one case where it's been very useful to be able to go back to meeting logs from more than a decade ago and see not just what sausage ultimately emerged, but what the sausage processing technicians were actually saying at the time.
If you follow the link to "full logs," there are meetbot logs (meeting 1, meeting 2) but keep in mind these are minutes taken down by our secretary and fed into IRC, so it's a high level summary that may be missing a lot and definitely not quotes of what was actually said during the meeting.
The code you have access to is all there, free to modify as you see fit. Branding is not code. Do not get the two confused. You do not get to mangle a project's name just to satisfy your ego. Read the license. Understand it. Personal attacks to me will not add anything to your point.
As the lead developer of Inochi2D, let me chime in. All of the code components of Inochi2D are under licenses compatible with the GPL, as such they are FOSS, or at the very least OSS. We predominantly use the BSD 2-clause license, but some components are under Boost and the MIT license. With a couple of components under (L)GPL.
Just because the software is FOSS doesn't mean I should have to deal with downstream distros breaking the package in weird ways and the support burden that entails. The reason why we have this split on what we allow to have our branding is so that it's far more clear that we do not provide support for distro-specific issues that may crop up. We do not have the bandwidth to support that when it's mostly just me maintaining and developing over 30 pieces of software.
I'm a Fedora user, but I very much agree that Flathub should be the default. Please stop breaking my userspace.
There is no serious debate about the trademark issue. Fedora is well aware of it, since we make some similar assertions, like you can't just make whatever Fedora derivative you like and call it "Fedora". We are not disputing the legal rights of any trademark holders. If a project wants to assert its trademark rights to not have Fedora include a package using a trademarked brand name or logo or whatever, we'd respect that. For obs-studio it is happening here - note https://pagure.io/releng/issue/12586#comment-955849 , "our choices are remove or rebrand".
Fedora doesn't package Inochi2D as either an RPM or a Flatpak or anything else, AFAICS.
There is no serious debate about the trademark issue. Fedora is well aware of it, since we make some similar assertions, like you can't just make whatever Fedora derivative you like and call it "Fedora". We are not disputing the legal rights of any trademark holders. If a project wants to assert its trademark rights to not have Fedora include a package using a trademarked brand name or logo or whatever, we'd respect that. For obs-studio it is happening here - note https://pagure.io/releng/issue/12586#comment-955849 , "our choices are remove or rebrand". Fedora doesn't package Inochi2D as either an RPM or a Flatpak or anything else, AFAICS.
You do not package Inochi2D, but you do package relevant software needed to build Inochi2D. For example the RPMs for the various D compilers on Fedora are broken and don't pull in necessary dependencies to link to the D runtime and core library, causing linking errors until you track down extra packages you need to actually link to the D runtime and standard library. And the versions of the D compilers often lack behind official builds, resulting in potentially broken builds due to how fast DLang evolves as a language. (eg. last time I checked you still package LDC2 1.39.0, some of my software depends on features I got merged in 1.40.0, so I've opted to manually install it into opt and overwrite the environment to search for SDKs from /opt/SDKs and add them to the PATH.)
Additionally, sometimes the build flags for said compilers restricts their use making them less useful compared to the official builds.
Additionally software like synergy is out of date in your repos, which prevents it from being used under Wayland, meaning I have to fight with GNOME Software to not have it downgrade synergy.
@lunafoxgirlvt Did you report any of the issues you mention (or sent a Pull request that fixes it)?
It's generally pretty difficult to find the exact place to report these issues, so no I have not. Especially when you go look up the package and find out that there's also COPR repos and the like that packages versions that are broken in different ways. Not to mention, it is generally recommended in the D community that you install the official packages anyways; or install manually if need be. Some issues are additionally far harder to directly track down, especially when packaged as a flatpak.
I do not have the bandwidth to spend an entire day just tracking down why something is broken in an unsupported build when I could just fetch an official build that works; especially since I know how to do that. The users that don't however, are in for a world of pain.
None of that seems to be on-topic to this discussion about flatpak repository priority or the sidebar about trademarks, though.
Synergy has been dead for a while now. The package was renamed to deskflow and it will replace synergy in Fedora 42.
deskflow
synergy
Additionally software like synergy is out of date in your repos, which prevents it from being used under Wayland, meaning I have to fight with GNOME Software to not have it downgrade synergy. Synergy has been dead for a while now. The package was renamed to deskflow and it will replace synergy in Fedora 42.
Nice, that at least solves one issue; my point is tangentially related to this overall. In that when a distro packages an upstream package; the usual assumption of a large majority of users will be to report issues to upstream; even if the breakage is downstream. Which is why it's important to prefer upstream packages on flathub, etc. if available.
That way we as developers don't get sent on a wild goose chase just to find out that it's an issue specific to that distro's way of packaging the software. It takes bandwidth we may not have for such shenanigans.
Edit: I want to add, that I don't mean this as an attack on any of the people who make packages for distros, It's difficult work and I know that painfully well in having done packaging myself before. However maintainer burnout is very real and something I've have to deal with myself. It's important to consider the balance between a distro's packaging freedom and not burning out upstream developers. Burnout is one of the ways we end up with dead unmaintained software after all.
The second one got messy because of the somewhat unnecessary arguing about Qt EOLs,
My goal there, in addition to summarizing our meeting, was to represent the strongest argument against my proposal. The argument in favor of Fedora Flatpaks is that Fedora has higher packaging quality standards and Fedora Flatpaks will provide a superior user experience than Flathub Flatpaks. I had been dismissive of concerns that Flathub package quality was inferior to Fedora's packaging; I didn't believe Fedora could actually do significantly better than upstream. Evidently I was very wrong.
Oof, please let's not phrase it that way. It seems clear there's a legitimate debate between "use a supported version of Qt that causes a serious known bug in the single application we are packaging" and "use an EOL version of Qt that doesn't cause the serious known bug". I think reasonable people can reasonably disagree on the correct choice there, and arguing about it and making declarations like "But still, on principle, keeping up with runtime updates is one of the most basic expectations of a maintainer, and I suspect it's a sign there may be other problems as well." isn't really helping.
I think it might be more constructive to phrase it as something like "Some members of the group disagreed with the upstream flatpak's choice about how to deal with newer Qt versions causing bugs in the application, and considered this a case where the Fedora flatpak made a better choice", no?
edit: I mean, if we had a clear story where we had provided significant additional value with the downstream flatpak here, that'd be a different story. But I'm not sure we can really make that case. If we had actively noticed the bug caused by the new Qt and, say, fixed it or worked around it, then filed an upstream ticket saying "hey, we noticed the new Qt broke your app! Here's a fix!" - the kind of value we actually do provide with downstream packaging work in a lot of cases, e.g. Python rebases - that'd be a different story. But AFAICS that's not the case, is it? AFAIK we didn't really even notice the bug downstream, or anything. There's no record in the commit log of the fedora flatpak that acknowledges it in any way. There's no bug report for it that I can find, no ticket for it.
Upstream is actively maintaining and testing their flatpak, they caught the bug, and made a reasoned decision that the risks involved in pinning an EOL runtime are not big enough to outweigh the bug. Any one of us might say we disagree with that choice or we have a better idea for how to handle the situation, but...AFAICS, we didn't do that, right? We didn't see the bug, we didn't do anything to address it. So I'm rather hesitant to give us too much credit for the downstream flatpak being "better" here. The downstream flatpak doesn't have an EOL Qt in it, but it does (presumably) have whatever bug the not-EOL Qt causes, and we didn't even notice. That's not a great story I'd be proud to tell the world either.
@comex
You're absolutely right with all of your points here. This is a very nuanced situation, which doesn't have a very clear right or wrong answer. We're forced to choose between "application works with EOL dependency" and "application is broken with non-EOL dependency". That's a hell of a choice for any maintainer to make. Fedora's opinion seems to be that upgrading is always the right choice, which we disagree with. There's nuance, and we have even sometimes found the upsides to upgrading are worth a slightly less functional application when there is a regression. We make this choice every single time when looking at dependency updates that might have regressions, and spend a ton of time weighing the options that are best both for our project, and for our users.
But to answer the question, yes, we will have a process in place to make sure we stay up-to-date with all Qt (and other runtime dependencies in the bundle) security issues and patches. The major difference is that we can align those updates with our actual releases instead of relying on KDE's releases. The cadence of KDE's updates this time was about as out-of-sync with our release schedule as it could be, and this is not typical of our project to go this long without updates. We already plan to update the runtime in our next release, now that the regressions were fixed in Qt 6.8.2 that released on Jan 31st, 2025.
This is not a lawsuit, this is an exercise of our trademark rights. No filings have taken place, we provided notice that we are prepared to invoke our trademark rights. Please be mindful of misrepresenting something like this in the future.
Thank you for this, we agree, and this has been our major point of contention.
In case folks find it useful, I dug this out of the archives: https://meetbot.fedoraproject.org/fedora-meeting/2022-07-12/fesco.2022-07-12-17.00.log.html
That's from 2022, when https://fedoraproject.org/wiki/Changes/UnfilteredFlathub was initially proposed in a form where flathub would have had priority over fedora flatpaks. FESCo rejected the proposal at that time; that's the meeting log. Most of the dramatis personae are the same, but note Eighth_Doctor from the log is @ngompa here.
My executive summary would be that there was a lot of nervousness about Flathub there - there were concerns around whether there was any auditing for security issues, whether some flatpaks were just secret-sauce binaries with no proper build chain, and so on. (And there was a sort of charming optimism that Fedora flatpaks would be popular and maintained on the same level as Fedora packages, which arguably has turned out not to be the case). There also seems to have been some specific concern about IDEs - apparently IDEs sourced from Flathub have/had limited functionality in some way. I'm not up on the details of that or whether it's still a current concern. It also seems like the proposal would have preferred sourcing from Flathub over Fedora RPMs, even on 'traditional' non-atomic Fedora installs (i.e. on Workstation as well as on Silverblue), and that seems to have been a point of contention.
That proposal was then revised to put fedora flatpaks before flathub in the order, and that version was approved in 2023, and that's where we now stand.
It'd probably be wise to use the log above as input to any new proposal and try to make sure all the worries that folks had in the 2022 vote are addressed up front.
With all the benefits that Flatpaks on Flathub bring, there's also an unfortunate paradigm shift: distributions move away from the status of essential packagers of upstream apps and become the unnecessary middlemen.
With no centralized app store such as Flathub, the issue at hand (OBS Studio quality issues when using Fedora's Flatpak app) would have probably brought upstream app developers and distro packagers/maintainers together in order to try to find a fix/solution to the issue.
There is seemingly no need for such a collaboration now, hence the outcome we've all witnessed.
I still think a thinner, more curated Fedora remote containing the core Flatpak apps shipped with atomic desktops, as well as any other package Fedora considers necessary to be there for various, justified reasons (e.g. upstream app on Flathub unstable, unofficial etc), should take precedence over Flathub.
Each runtime on Flathub (Freedesktop, Gnome, KDE) is itself a small Linux distribution minus a kernel, GUI, and systemd. They need regular maintenance with security patches and bugfixes just like any other distro. The main philosophical difference between them and traditional distributions is that their maintainers focus exclusively on delivering a foundation for other developers and don't try to package the world.
Traditional distros, on the other hand, aim to provide complete and curated experiences for end users. Their goal is to make all programs needed by users a mere apt install or yum install away.
apt install
yum install
The complaints about Fedora flatpaks would be just as valid if a developer certifies and packages their application for Ubuntu 22.04, and then hordes of RHEL7 users bug the developer about issues in an RPM of the app from EPEL. In fact, they are similar to a recent kerfuffle between the KeepassXC developers and Debian packagers. Does Debian's Gnome Software also prioritize Flathub over their own packages?
To provide some context to my previous comments, I am not against removing the RPM support (and deprecating Fedora Workstation in favor of Silverblue and other Atomic variants) and I actually think that in order for desktop Linux to succeed, it needs to abandon the concept of traditional packaging systems (that will always bring potential dependency issues and other problems to regular users and are unpredictable in many cases). It just needs to be done in a good way. Such way in my opinion means making sure that the majority of (desktop) apps currently available in regular repositories is available in the Flatpak form, and also making sure that there are no major limitations of at least the most popular apps when compared with their RPM versions before removing the RPM support. Currently, the biggest problem in my opinion are apps that require custom system daemons / user space drivers running with system privileges and/or custom udev rules.
I also think that the "Fedora Linux" Flatpak remote should definitely be kept and used at least for core GNOME/KDE and other core (preinstalled) apps. While Flathub is great, it is still a "single point of failure", also apps from there cannot easily contain custom (Fedora) modifications and other (branding?) distribution-related stuff.
We discussed this for a third time at today's Working Group meeting, again spending the entire meeting on this topic. We still do not have consensus and will hold a fourth (hopefully final?) meeting next week for further discussion, but the Working Group seems generally much more skeptical of my proposal to remove the Fedora Flatpak remote, and I'm no longer confident that the Working Group will make any changes here.
What do you think about the proposal that, when the user enables third-party repositories, Flathub should be given the highest priority over other packages? Has there been any consensus on this?
I think we probably have consensus to not prioritize Flathub at this time. I'd like to think that it might be possible in the future if Flathub were to tighten its package quality guidelines, but this would require further discussion as the Working Group has not agreed to it yet. I don't think Flathub needs strict guidelines like Fedora has, but it shouldn't be wild west either, and the standard today is clearly too low. Flathub needs some basic bare minimum basic quality rules like no precompiled dependencies allowed.
We'd probably also need Flathub to segregate free software from nonfree software; so long as it's all clumped together into one repo, we cannot enable it by default, and that makes it much harder for Fedora to promote it. It would be very nice if this barrier could be removed, such that we could just enable Flathub out of the box for all users (regardless of where Flathub sits in the priority list). We could conceivably then replace the existing "enable third party software" preference with an "enable proprietary software" preference.
So those are two actionable tasks that would help a lot, and I think it'd be useful for Flathub community members to go work on those. But again I caution that the Working Group does not actually have consensus on this yet, so what I'm trying to do here is outline a possible compromise; I'm not promising the Working Group would definitely agree to this. We still need further discussion. It might not be possible to reach consensus on promoting Flathub software above Fedora software regardless of how much Flathub improves.
In the meantime, I am going to moderate my ambitions and continue to argue in favor of removing the Fedora Flatpak remote, such that we'd have Fedora RPMs as highest priority source in GNOME Software, followed by Flathub if it's enabled. But again, I'm beginning to fear the Working Group will not accept my proposal. And this would presumably be limited to Fedora Workstation and would not affect Silverblue at all. Notably, Fedora RPM software source does not exist in Silverblue; since we will not enable Flathub by default, if we were to remove the Fedora Flatpak remote like I propose, there would be nothing available to install in Silverblue's GNOME Software besides the few preinstalled Fedora Flatpak apps.
Well, that sounds unfortunate.
Are we considering any other more systematic way to resolve cases like the one that prompted this whole ticket (the obs-studio case)? Some kinda way to change the preference order on a more granular basis, or a clear process for removing Fedora flatpaks on request from upstream, with some solid criteria for doing so?
At the very least, there needs to be something in the repackaged Flatpaks that identifies these as a Fedora versions to help point users to the proper support. Communication and proper labeling would help clear up a lot of confusion and potential with the original software developers.
I would prefer to leave that up to the Flatpak SIG or FESCo.
The Workstation Working Group will set high level policy for Fedora Workstation, and we'll intervene in the maintenance of software that is shipped by default in Fedora Workstation, but I'd say OBS Studio and other extra software not shipped with Fedora Workstation is somewhat outside our purview. There is a separate Flatpak SIG issue report already for this.
Some kinda way to change the preference order on a more granular basis
Chris has supported this, but frankly I think it's a bad idea. Even just having three different software sources is already too complicated in my opinion. I'd like to create simple rules that are easy to understand (e.g. Probably Safe Flathub > Fedora RPMs > Potentially Unsafe Flathub), not case-by-case exceptions.
or a clear process for removing Fedora flatpaks on request from upstream, with some solid criteria for doing so?
My proposal is to remove everything unless we have some special/unusual compelling reason for packaging it. The Flatpak SIG does not agree and I think it's up to them. My counterproposal is to create a separate Fedora Flatpak source with only preinstalled applications that we would use for Workstation and remove the existing repo, but the Working Group does not have consensus for this.
Well I think the software source is already pretty clearly marked in GNOME Software. Beyond that, I'm really not sure what you're looking for? Theoretically, Fedora could fix up appstream metadata to point users to Fedora communication channels instead of upstream, but I doubt most users would actually look at those, so I doubt it really matters much. I guess we could rename every application such that it ends in "(Fedora)," but this will surely annoy users and is probably a nonstarter. Not sure what else we can do.
yeah, with that the problem is there's no 'standardized' way to do it, really. There's no universal standard for apps to identify themselves or point to support resources; obs-studio doesn't do this the same way Bottles or Firefox or Evolution do it. Changing those requires patching on a per-package basis (and those patches are likely to go stale any time upstream changes the information or the UI).
I do wonder if we could make it more clear in the Software UI...somehow. I'm not a UI designer, though. I'm not sure I agree that it's "already pretty clearly marked" - it does at least seem like in the current case, enough folks are not understanding this that it's caused problems for upstream.
@catanzaro "My proposal is to remove everything unless we have some special/unusual compelling reason for packaging it. The Flatpak SIG does not agree and I think it's up to them"
Where is "the Flatpak SIG" discussing this? In Workstation meetings, or elsewhere? Is there any record of the proposal being made to them or their decision on it? Who is in "the Flatpak SIG" at present?
I don't see any ticket at https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues besides the obs-studio specific one - where I don't see any clear record of that proposal being made or rejected. The SIG page claims "Flatpak SIG meetings are held every second Monday at 15.00 UTC", but I just checked the last month at https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/ and I see no record of a Flatpak SIG meeting. The most recent one I can find by looking in the teams view was in April last year, when only @yselkowitz and @kalev said anything.
At the very least, Fedora Silverblue specifically is sending a clear message to users if it does not enable Flathub as first priority when third-party repositories are activated: "Go use another distro." The unfortunate reality is that many newcomers will end up on alternatives that are less aligned with the values of free software, such as Ubuntu or certain Fedora derivatives that integrate Flathub seamlessly.
Let’s be realistic—if we conducted a survey, over 90% of Silverblue users rely on Flathub. Please, at the very least, conduct the survey before making a decision. New users need a functional repository that allows them to do basic tasks, like playing videos or using applications the way upstream intended.
It does enable Flathub. The issue is that we also configure GNOME Software to default to installing from the Fedora Flatpak remote rather than the Flathub remote when a given app is available from both. The initial proposal here was to flip that order or remove the Fedora Flatpak remote from the default config entirely.
There are other ways to install flatpaks which don't behave the same. Command line flatpak install always requires you to actively choose between the possible remotes (which is a bit cryptic if you don't know what's going on, I guess). KDE's Discover, according to @ngompa , also makes the choice more explicit (though I haven't yet got around to looking at the UI myself so I can't say precisely how it does that).
flatpak install
To call back to my "different perspectives" post above: for Fedora folks, remember we've been navigating this kind of issue with packages for decades. It's not exactly new. We've had to disable certain video codecs and so on in our official packages for years (hands up who remembers DVD CSS!) It hasn't yet, you know, killed the distribution, though it definitely is a factor you see people cite when choosing. So Fedora people are likely to not immediately set their hair on fire if the problem is "the build we ship of app X has some stuff disabled for patent reasons".
The difference in the current case is that flathub kinda potentially gives us an option we didn't have before here. In the past, AFAIR, the advice we've gotten has always consistently been that we can't promote or offer third party repos that do stuff we aren't supposed to do ourselves. It seems like that's different with Flathub, though I absolutely couldn't say why. So it changes the calculus a bit. But it's, again, not an immediately obvious "slam dunk" to distro people that we should completely change our decades-standing approach to third-party repositories because of this. It's still a case that needs to be made (and from the sounds of it @catanzaro is having difficulty convincing folks of it).
I see in Gnome Software (Fedora 41) that the Flathub build of OBS Studio is "Verified" while the Fedora flatpak is not:
<img alt="Screenshot_From_2025-02-18_14-25-01.png" src="/fedora-workstation/issue/raw/files/faa312854970db4c116a2099e0f20dc148e0eac7c978635102751af64cd585b8-Screenshot_From_2025-02-18_14-25-01.png" /> <img alt="Screenshot_From_2025-02-18_14-25-23.png" src="/fedora-workstation/issue/raw/files/d4088d8fc20e1db45ed84ff20cb1e5e76736d050af9094de11a0e15dd144c297-Screenshot_From_2025-02-18_14-25-23.png" />
So prioritizing "Verified" channels would at least resolve the case of OBS Studio.
yeah, that's one of the alternatives that's been proposed, e.g. in https://pagure.io/fedora-workstation/issue/463#comment-952080 . I don't know if they were brought up in the recent discussion (see the thing above about video meetings, sigh).
It was brought up, and in principle, we're not against the idea. However, I am against the idea of doing this without having a UI in GNOME Software for users to customize their software source priorities.
ngompa: However, I am against the idea of doing this without having a UI in GNOME Software for users to customize their software source priorities.
Until such a UI feature gets developed in GNOME Software, we could inform users in the docs (QuickDocs maybe), that they can change priorities via CLI, e.g.:
gsettings set org.gnome.software packaging-format-preference "['flatpak:flathub', 'flatpak:fedora', 'rpm']"
At this point, the Flatpak SIG seems to be just Yaakov, who attended today's Workstation meeting but not our previous meetings. My understanding is that everybody else has quit? They have a wiki page with a list of people interested in joining, but it was created two years ago and hasn't been updated to reflect actual membership.
The difference in the current case is that flathub kinda potentially gives us an option we didn't have before here. In the past, AFAIR, the advice we've gotten has always consistently been that we can't promote or offer third party repos that do stuff we aren't supposed to do ourselves. It seems like that's different with Flathub, though I absolutely couldn't say why.
Unfortunately I think I'm not supposed to explain the concrete legal reason for this difference, but suffice to say that that Fedora Legal does not impose limitations on what we can include from Flathub like it does with RPM Fusion, so how much of Flathub we expose is a project choice. I assume it will be almost impossible to enable proprietary software sources by default due to Fedora's foundational preference for open source, which is why I suggest splitting Flathub into two, but that's something Fedora community can change if it wishes.
We could also theoretically use the Fedora Flathub filter for this purpose. When you enable third-party repositories in Fedora, technically you are enabling a filtered view of Flathub that filters out nothing. The filtering mechanism is still there even though it doesn't filter anything anymore, just in case we need it for some reason in the future. (However, I think it would be nicer to use the filter only for emergencies.)
I just assume we will have to expose this preference in the GUI as part of any compromise.
The proposal to prefer verified sources has actually already been implemented here, but with a big caveat: it is secondary to the existing packaging-format-preference setting, so it doesn't work the way proponents want it to. A Verified Flathub app will by default only take precedence over sources that are not in the priority list, so this will cause Flathub to be preferred over other third-party repos like GNOME Nightly, but not over Fedora sources.
(Also keep in mind that apps control their own appstream metadata and can simply mark themselves as verified. And this is Fedora Workstation's software center, so somebody could plausibly propose to mark all Fedora software as verified.)
It does seem to me that there are maybe procedural issues with decisions being deferred to a SIG which, on the face of it, has one active member (who is also the person building a lot of the flatpaks at issue) and no active formal decision-making process...
Do you think it would be productive to escalate that aspect of the situation to FESCo somehow?
I assume it will be almost impossible to enable proprietary software sources by default due to Fedora's foundational preference for open source, which is why I suggest splitting Flathub into two, but that's something Fedora community can change if it wishes.
By the way, I think it will be drastically harder to change this than it would be to approve Flathub taking precedence over Fedora software sources.
With regards to OBS Studio specifically: I understand the OBS Studio developers are meeting with Yaakov today. I'd say it would make sense to escalate if they are not satisfied with the outcome.
With regards to Flatpak packaging strategy: sure.
With regards to source prioritization: if the Working Group decides to change anything, we'll do so via a change proposal that will have to be approved by FESCo. If the Working Group decides not to change anything, or if people are not satisfied with the Working Group's decision, then it would certainly make sense to escalate to FESCo. But I'd ask for a little patience for now, as we don't yet have a Working Group decision. We probably won't need too much longer.
Thanks. Yeah, I meant the "Flatpak packaging strategy" part, as that seemed to be the part you were deferring to the Flatpak SIG.
I think rebranding is functionally the best bet, it's just a matter of striking a balance between disambiguation and UX. We could maybe use GOG.com as inspiration - they often ship the same games as Steam, but they have a distinctive icon style which is a dead tell for the user if a certain game on their computer is from GOG. <img alt="1000111602.jpg" src="/fedora-workstation/issue/raw/files/8ab722eda879710d05774e775f1d18466d581e13d56c2b19d7422c336c245d8c-1000111602.jpg" /> It's still using either the official icon or official artwork, but the mask they apply on top is very distinctive and unambiguous.
If we combine that + a different version number(for example, "AmazingApp 3.14F" vs "AmazingApp 3.14"), there are both visual tells for the user as well as naming tells for upstreams(since the user is usually asked to supply the version number in bug reports). Having it as "3.14FF" and not "3.14-fedora" is so people don't mistakenly assume it's irrelevant and omit it from the bug report; having it "semi-concealed" like this makes them assume it's just part of the versioning scheme, and so will be much more likely to report it verbatim.
Well maybe I'm the only other member of the Flatpak SIG as I'm the only flatpak tester lol right now. Anyway all I can say and some of this is influenced by end users. There needs to be some clearer info on why to use Fedora Flatpak or Flathub. As was mentioned maybe somewhere on screen where it asks if you want to enable third party repos or not. For example as one user said, "The OBS package from Fedora flatpak does not include, some codec he used. He says it rendered OBS useless. Where as the Flathub package did have the codec. Now I dont know enough about the program to note if thats really the case or not. I know maybe its because its a proprietary thing?
Anyway just trying to keep the new user perspective. If they are new to Linux and or Fedora how would they know if they should use one or the other? During the installation?
A Fedora user of 6 years here. If I'm reading this right, the problem at hand is wanting to deprecate RPM-packaged apps in favor of Flatpak ASAP, hence Fedora Flatpaks; correct?
I, for one, am convinced that the main point of Flatpak is being able to get distro-agnostic software directly from the developer(s). A distro being both an OS and an app store "at home", with unrelated people packaging someone else's software, is an ugly anachronism we're slowly, but surely leaving behind. And if that's the future we want, we'd need to admit that any potential issues of third-party software are not – and should not – be an OS' responsibility; creating a presumably more secure yet broken surrogate Flatpak packages might end up not only souring your relationship with the upstream (as seen here), but also misleading some users into believing that Flatpak itself is a problem (saw such sentiments on Reddit recently).
Now, I'm all for a flourishing Flatpak ecosystem, but let's admit it: we're not there yet. And if we want to get there, we should be working with the upstream – not against it. Sure, there still are numerous... distro absolutists out there (like a certain DeVault), but they will go the way of the dodo – it's just a matter of time. Rome wasn't built in a day, and we have to be patient. Incidentally, here's a possibly inspirational example of how developers were hesitant about Flatpak at first, but ended up embracing it: https://github.com/keepassxreboot/keepassxc/issues/1524
Now, for my $0.02: Fedora Flatpaks, in general, are a waste of time at best (with a bit of the sunk-cost fallacy sprinkled in), and something outright harmful at worst; I think that distro-provided Flatpaks (if any) should only be ever made for apps whose developers have an irrational aversion towards this kind of software distribution (mpv comes to mind).
Thank you for coming to my TED Talk. Hasshu, over.
@hasshu
I, for one, am convinced that the main point of Flatpak is being able to get distro-agnostic software directly from the developer(s). A distro being both an OS and an app store "at home", with unrelated people packaging someone else's software, is an ugly anachronism we're slowly, but surely leaving behind.
As desktop Linux users we have so far been insulated from this problem, but you should Take Notice of the fact that on other OSes that have a primary culture of developer-originated packaging (Android, iOS, Windows, Chrome extensions), a lot of the packages contain malware. This is entirely independent of packaging quality considerations, but rather because some developers are grossly misaligned with user interests, are actively malicious, or have been suborned by someone who is.
Yselkowitz currently packages, at last count I had checked a week or so ago, 1378 packages. In what world is a single person able to maintain, test, and support, that many packages and applications? The entire initiative seems poorly planned, badly implemented, and is largely unsustainable.
[...]
I second this. CI/CD is not a substitute for Actually Firing Up the Program and Seeing if it Works. I find it hard to believe a single person is able to give a reasonable amount of QA attention to such a large number of packages, unless they are almost all frozen. And revving dependencies is not frozen.
If I'm reading this right, the problem at hand is wanting to deprecate RPM-packaged apps in favor of Flatpak ASAP, hence Fedora Flatpaks; correct?
Not entirely, no. This ticket is about the preference order between two different sources of Flatpaks. Where the RPM source should be in relation to those two is a complicating factor, but not the main thing this is about.
Sorry to spam the thread, but I just wanted to say thanks, @fenrirthviti, for the reasoned response to the fairly sharp comment I made previously.
Maybe a bit of an aside but it drives me a bit mad when upstream software developers say "oh no we need a highly specific version of our dependency" but this fact is relegated to effectively secret knowledge and then later used to justify why external packagers are broken and should not be used (or alternatively, "we have redesigned our project to not use system dependencies because system dependencies cannot be trusted").
You possess a build system, it is utilized for detecting said dependency and it turns out that this even tells you what version you found! :) If only certain versions are acceptable then... say so? Emit a message(FATAL_ERROR "versions above XXX are broken due to LINK! Edit: now fixed in version YYY, please upgrade")
message(FATAL_ERROR "versions above XXX are broken due to LINK! Edit: now fixed in version YYY, please upgrade")
It's good for documentation, it's good for tinkerers trying out your project and building from source, it's good for distro packagers. I hardly think that Fedora is going to get horribly mad at you for stopping them from using something that you are objecting is broken! Maybe they will enthusiastically help fix the bug, maybe they will backport it once it is fixed, maybe they will temporarily pull it from fedora and advise using your flatpak in the meantime, maybe they will watch the ticket for updates. Maybe, they will even patch out the check and you can get mad at them for that instead. There is no situation where more information isn't helpful.
Today, that version check is still useful, but lacking and nowhere to be found, in order to guarantee that users have updated from 6.8.1 to 6.8.2.
One thing is for darned sure. If you're worried about the feasibility of staying on top of every downstream redistributor across umpteen distros and making sure they aren't doing a bad job and giving you a bad name in the process, it is INFINITELY easier to communicate your requirements to those redistributors if you, well, communicate those requirements. :)
Special mention to:
This particular comment feels a bit reductive. The runtime we haven't updated is Qt itself, the reasons for which are well documented and a particular pain point for us.
There is no documentation whatsoever there. At least the issue is pinned. But the initial response was
The runtime will be updated when we switch to a new Qt version.
which didn't even acknowledge the existence of bugs, it took half a month for someone to pry out an answer in the form of "but it could be postponed if there are more regressions in the new Qt version" which still provides no details and was thereafter locked after a frankly combative reply to the query "is there somewhere that collects information about what problems there are about upgrading".
No, we usually don't have issues for dependency updates unless there is some critical reason it needs to be updated. This is just an overly dramatic warning in a package manager.
This is stunningly informative! No links to a closed issue where it was previously discussed, just "no we will not do this" followed by a reluctant "if you must know, there are regressions, sorry we won't tell you what the regressions are" and "TICKET LOCKED AS OFFTOPIC".
Please, don't go around claiming the reasons for not upgrading are well documented. Respect is a two-way street.
@eschwartz
Thanks for the feedback, but probably best to keep this thread on-topic, as it's already exploded beyond what the original point was. We're already considering adding maximum supported versions to our build system, but that opens an entire other can of worms and is a discussion not suited for this thread.
I think that to an extent it is reasonably well suited to this thread, as it's about respect for upstream projects by distros, so by extension we should be discussing respect for distros by upstream projects.
I was originally pretty sympathetic to OBS's side of things when I first heard about this spat. I was going to gently comment about maximum supported versions, but then I actually clicked through to the OBS github discussion and it was disappointing enough that I don't know how else to say this. I lost ALL respect for your side of things.
Frankly I consider it borderline malicious behavior to act all secretive and squelch anybody who tries to ask you what the problem is with Qt 6.8 and then get all indignant when nobody from a distro knows what the problem is either and go around threatening scorched-earth trademark enforcement because of the bugs nobody knows about. I think it weakens your argument to the point of virtual nonexistence. It's plain that far beyond not declaring maximum supported versions, you actively wish to prevent anyone from finding out whether your software has bugs.
I don't understand why. A far-out theory is that you are trying to deceive distros into packaging a buggy version so that you can then cry foul. It is implausible, but then again, so is your suppression of information in the form of draconian github moderation when people ask simple questions so they can better understand your supported versions.
If you go looking for enemies you're certain to find them.
Please consider fixing your public user interactions, not just your CMakeLists.txt.
The bugs were discussed, reported, and made known to what we determined were the appropriate parties, which was part of the whole problem to begin with; nobody on our side knew who the right person to talk to was and we weren't getting any direction or advice. I'll admit that we could have made a fully detailed post for any random passerby to find, but it wasn't a priority and anyone asking us directly about it was provided an answer. It didn't seem like effort well spent at the time, as pretty much anyone engaged with the project (including several people commenting in those threads) already knew the exact technical reasons and knew about our QTBUG reports. To be frank, I thought we had an issue post about the specific regressions, and was kind of surprised myself when I found we didn't. Sometimes we forget to log that stuff publicly for people not as engaged. Because of the volume of discussion we have about it, it can be easy to forget that not everyone is watching everything as closely as we are. I don't think we're the first, nor the last, nor the most egregious example of this and I like to think we generally do log these kinds of things pretty well when they do come up when they affect users and developers.
I can assure you that people who were in a position to take action were made aware of the issues, either via Discord, Matrix, or other communication channels that weren't a GitHub issue post. Jumping to conclusions that there weren't conversations, information, and details just because they weren't meticulously logged and published in the public eye isn't fair to us either. I pointed to what was there, as proof we made a conscious choice not to upgrade. Probably could have worded it better here to focus the point I was getting at, and I'll eat that as a small mistake on my part because I'm not unwilling to admit when I make a mistake. Everyone makes mistakes. I don't think that disqualifies our complaints, justifies the treatment we received, or is nearly as serious of a problem as you're portraying it. That said, I understand your point of view, and I'll keep in mind in the future. I trust you'll make an attempt to understand ours as well.
Happy to provide further information off-thread if you like, as the technical specifics of the regressions aren't relevant at this point (and have already been resolved), and never really were. Both sides have already had conversations and hashed it out, and we're ready to move past this.
@yump I see your point, but I find it hard to believe that malware-ridden packages are nearly as common on other platforms as you suggest (may depend on your definition of "malware", I guess?). Not to mention that the recent XZ Utils backdoor was discovered not by an army of ever-vigilant distro maintainers, but by a Microsoft employee – accidentally at that. Proper security audits take a lot of expertise, time, and (often) money.
@adamwill Thanks for clarifying. Frankly, this topic is somewhat difficult to follow at this point...
Are you at least going to prioritize adding Flathub as the default option when users enable third-party software?
The current situation is getting out of hand and is seriously damaging Fedora’s reputation—possibly beyond repair. Personally, I’m even considering switching to another distro because I see no future in a project where people are so adamantly opposed to respecting user choice.
The Fedora Project Leader is willfully ignorant about Flathub: - Reddit thread - Blog post
Workstation Working Group continued to discuss this proposal at this week's meeting. I think we're roughly evenly split on what to do. We are going to require further discussion and will need to consider possible compromises.
One possible option proposed by Christian is that Fedora Flatpaks must be owned by the Fedora RPM maintainer, which would still allow Fedora RPM maintainers unrestricted ability to create Flatpaks for anything, but in practice would likely lead to a drastically reduced set of Flatpaks.
Have you discussed the lack of codecs on Fedora Flatpaks and how to overcome that limitation?
We will definitely need to make H.264 available via Cisco.
Other missing codecs are probably missing because they require royalty payments to rightsholders. Red Hat will not provide funding for this. If you are a billionaire, let's talk. Millionaires are probably not rich enough. Otherwise, it is certainly possible for third parties to offer Flatpak extensions, so feel free to talk to a third-party project like RPM Fusion or start a new such project. Fedora is prohibited from helping with this, but it should be possible to do separately from Fedora if you wish.
I'm not a millionaire, but I'm considering selling Fedora Laptops, and this information could be vital for my decision to maintain the Fedora brand without any name changes. Do you know if H.264 support through Cisco will be included in the next Fedora release?
It's already included in Fedora Workstation, and has been for a while. (H.264 support is enabled after the first system update, since we cannot include it on the install images. See #84 for history.) But this is for the host operating system only and does no good for Flatpaks.
Flathub Flatpaks have access to both OpenH264 and ffmpeg via runtime extensions, but Fedora Flatpaks do not. So it's only Fedora Flatpaks that are missing H.264 support currently.
Update from our fifth meeting on this issue:
We're tentatively pursuing this approach and have a draft position statement, but it's not ready to share yet as we're still working to reach consensus. But at least gears are turning....
Unfortunately, Flathub is not a good option for anybody who cares about security. In my experience, very often apps are not built from source on Flathub's servers, instead a precompiled binary is simply downloaded during the build process. There is no way to be sure that the software you're installing was built from its source without injecting any proprietary parts or malware. In practice, it can't be verified for Fedora packages as well (GNU Guix is the way it should ideally be done), but Fedora has strict rules about only allowing FOSS software and one only need to trust a single infrastructure to compile the packages.
In Flathub's case sometimes an app is built on their infrastructure, or it can be the infrastructure of the app's project, or simply the developer's laptop which, even if you trust that developer, can itself be compromised. It's a security nightmare and totally unacceptable in my opinion, but it seems like nobody cares. I really like the ideas behind Flatpak and I think it's a step in the right direction for the Linux community, but I don't see how Fedora can rely on flatpaks without maintaining its own repository.
Most of the apps on my Fedora system come from Fedora Flatpaks and they work very well. I only have 3 apps from Flathub that I manually verified (one of them with disabled network permission). In fact, I was very happy to see that the number of apps is growing and almost everything I need is now available from Fedora Flatpaks. I actually had a hope that Fedora Flatpaks will become more popular (also among users of other distributions) and compete with Flathub, but seems like it's not happening.
If Fedora Flatpaks are abandoned or the number of apps available is substantially reduced, I personally will have to go back to RPMs as I don't see another option to use Flatpak.
The Workstation Working Group has approved the following position statement:
We see packaging desktop applications as Flatpaks as the future of the Linux ecosystem. We also expect that over time immutable OS models, like Silverblue and Bluefin, will become a major subset of desktop Linux distributions. This has several consequences. First of all we, expect that at some point we will stop offering RPMs through GNOME Software, our software store application. That point is not now because there are still cases where applications only work well as a RPM, but over time we expect to work with the wider Flatpak community to resolve the remaining issues and move to a situation where Flatpaks is our main model for desktop application delivery. (There will be other store type applications too, like Steam, as an example.)
RPMs will still have a place, both as something that can be installed with the DNF command line tool, but also as a building block technology for various container technologies like Flatpak, Podman containers, etc. As we discuss various topics below they apply in many ways equally to RPMs, but we choose not to spend time on that as our expectation is that GNOME Software eventually will only offer Flatpaks and thus the question of whether there is an RPM or not becomes less relevant.
Another item that came up in this discussion was around situations when upstreams do not want us to distribute their application. The first thing to say here is that distributions doing this have a long history in the Linux community and most applications are even relying on the distributions doing this, so the situation where this is a point of contention is the exception not the rule. This is a bigger question going beyond Flatpak specifically, but we think it is fair to say that the consensus in the Fedora community is to try to accommodate our upstream partners as far as possible. So we would encourage the wider Fedora community to adopt a written policy that clearly states that Fedora will always respect other peoples' trademarks and also try to treat upstream project names as representing the identity of the upstream project even if they are not formally trademarked. That said, there might be cases where we have strong reasons to want to ship something even if the upstream do not want us to and which we are entitled to under the open source license, but in those exceptional cases we should go the "Iceweasel" route and rebrand our version. And to be 100% clear, respecting trademarks has always been a Fedora policy, but we think there is room for improvement in terms of having more documentation around it for packagers.
Flathub has established itself over the last years as the premier site for Flatpaks and has become the main source of applications for a lot of people. We support the Flathub effort and want to see it succeed, which is why we have worked to integrate the enabling of Flathub into Fedora Workstation and were also among the original contributors to Flathub infrastructure. At the same time we have invested in making it possible to build Flatpaks in Fedora infrastructure as we need this for various use cases, such as making pre-installed applications for Silverblue, but there are also cases where we might want to make different choices than what is being done on Flathub. A good recent example of that is Firefox where we, due to our heavy investments into MIPI camera support and PipeWire, started shipping PipeWire camera support in our Firefox RPMs and Firefox Flatpak already, while the Flathub package still doesn’t. Being able to help drive technologies forward and leading the way for the Linux community in terms of moving our technology stack forward is a core mission for Fedora and thus we need the freedom to be able to do this. There are a lot of other hypothetical situations here too, like for instance we expect Fedora to be a leader in driving quantum-resistant encryption forward, so just like with the Firefox Pipewire support we might be switching to different crypto libraries before the community in general does.
So our stance is that Fedora flatpaks will be preferred over Flathub ones, but that also puts a lot of responsibility onto the Fedora packagers. We don’t see a strong need to make Fedora flatpaks out of everything "just because," so we ask all Fedora contributors to ask themselves a few questions before deciding to go down the route of making a Fedora Flatpak in cases where there is one on Flathub.
The first question is if our Flatpak will be just as good as the one upstream. If there are features we disable for various reasons or vendor keys we are not able to include, then it is probably better if we don’t ship our own Flatpak because we don’t want people to end up with a less functional version of the application.
If the upstream in question does not want us to create a separate Flatpak, even if its functionality is identical, then once again ask yourself what is actually gained by repackaging this in Fedora.
Are you the owner(s) of the RPM? We want there to be a single owner or owners of packages in Fedora, and thus packaging something as a Flatpak where the RPM packager is not involved is not generally a good idea. Both in terms of error reporting and in terms of general maintenance, having this split means that issues might not get resolved or users get annoyed feeling like they ping-ponged between upstream, Fedora Flatpak maintainer, and Fedora RPM maintainer. So if the RPM maintainer is not interested in working on also having a Fedora Flatpak, that is a strong reason for not making a Fedora Flatpak.
How are you going to handle error reporting? Do you have the time and resources to be an intermediary between the users of your Flatpak and the upstream developers? Are you able to actually maintain your Flatpak in a real way? Or are you just rebuilding something and hoping it works?
If the answer is negative to any of these questions, our recommendation is that you probably do not want a Fedora Flatpak made of this application. There might of course be corner cases where the answer is no, but it is still the way to go, but we expect that to be a tiny minority of cases.
Fedora Workstation's main audience are developers and content creators. This is a technical group of people who in general are able to handle and often expect more control of their system than the average user. Thus offering them the ability to configure their repository priorities as a way to help deal with the complexities involved here is something we want to do. While this wouldn’t make as much sense for a generic global audience, we do think that for the Fedora Workstation user base it matches their expectations.
Some thoughts from me:
Are you the owner(s) of the RPM? We want there to be a single owner or owners of packages in Fedora, and thus packaging something as a Flatpak where the RPM packager is not involved is not generally a good idea.
Almost none of the existing Fedora Flatpaks would meet this criteria. However, the position statement notably does not say what to do with all the Flatpaks that already exist, and it also notably does not prohibit any packager from creating a Fedora Flatpak for any package. So, this statement does not actually resolve the problems here. But it gives us a reason to ask "why do these Fedora Flatpaks exist?" It shifts the burden from justifying why to not package an application, to justifying why should we package the application.
Fedora Workstation's main audience are developers and content creators
This does not mean we design the operating system for such audiences, but rather than it is strategic for Fedora to target such users.
Thanks a lot. That's a position that I can get behind.
So, this statement does not actually resolve the problems here
Indeed. What should happen to the flatpaks that already exist? Do we want to move those which do not meet the criteria to a legacy repo? How are users going to be affected who already have some of those flatpaks installed? ...
First of all we, expect that at some point we will stop offering RPMs through GNOME Software, our software store application. That point is not now because there are still cases where applications only work well as a RPM, but over time we expect to work with the wider Flatpak community to resolve the remaining issues and move to a situation where Flatpaks is our main model for desktop application delivery.
Just a question: If Fedora Workstation continues to exist at this point, do you realize that this will require replacing all pre-installed apps (except system ones) with Flatpak versions?
I doubt we'll ever upgrade users' apps from RPM to Flatpak. It would presumably only affect new installations.
I was of course talking about new installations, not existing ones. Removing support for RPM apps from Software, but having the pre-installed apps as RPMs instead of Flatpaks even for new Fedora installs would, with all the respect, not make any sense and would lead to a very bad user experience.
Of course we would not preinstall RPM apps if removing RPM support from gnome-software.
What is going to happen to Flatpaks on the Fedora repo that depend on codecs? Have you found a solution for that?
Example: No codecs on Kdenlive = bad user experience for 90% of users
That's specifically mentioned in the position statement.
"The first question is if our Flatpak will be just as good as the one upstream. If there are features we disable for various reasons or vendor keys we are not able to include, then it is probably better if we don’t ship our own Flatpak because we don’t want people to end up with a less functional version of the application."
I will propose the following change for the Atomic Desktops for Fedora 43: https://fedoraproject.org/wiki/Changes/FilterFedoraFlatpaksAtomicDesktops
If the Workstation Working Group is interested, then we could make this a more broadly scoped change instead of having it focused on the Atomic Desktops only.
Feedback welcomed.
This will be pretty bad for non-x86 architectures, since most of our Flatpak coverage comes from Fedora for those. I would rather not do this change period.
And this Change is not aligned with our position as we voted on last week, either.
(Also, I am not really enthusiastic about this for Fedora Kinoite either.)
I think it is consistent with the position statement for last week: we would only offer Fedora Flatpaks if we have some particularly strong reason to package them, rather than packaging everything. I actually don't see a plausible path towards implementing the position statement otherwise. In particular, we need to decide what to do with all the Fedora Flatpaks that are not maintained by the owner of the RPM, and a filter would solve that.
Flathub has good coverage for aarch64, right?
It's indeed devastating for ppc64le and s390x, but I think very few users care about those.
And this Change is not aligned with our position as we voted on last week, either. I think it is consistent with the position statement for last week: we would only offer Fedora Flatpaks if we have some particularly strong reason to package them, rather than packaging everything. I actually don't see a plausible path towards implementing the position statement otherwise. In particular, we need to decide what to do with all the Fedora Flatpaks that are not maintained by the owner of the RPM, and a filter would solve that. This will be pretty bad for non-x86 architectures, since most of our Flatpak coverage comes from Fedora for those. I would rather not do this change period. Flathub has good coverage for aarch64, right?
Not really. ARM Flatpaks are mostly broken on modern ARM platforms due to usage of older software stacks and such (I cannot cite the details as they were from a deleted fedi account). It's one of the reasons Flathub Flatpaks are heavily discouraged on Fedora Asahi Remix.
https://yselkowitz.github.io/blog/2025/02/25/the-case-for-fedora-flatpaks.html
This position statement and any change proposals coming therefrom are an attack on my work and the work of everyone who is packaging desktop applications in Fedora. Furthermore, this WG does not have the authority to decide what should be packaged in Fedora, only what is featured in the Workstation edition, and even then within the guidelines provided by FESCo, who already decided that Flathub content must not take priority over Fedora content. The statement and change proposal should be withdrawn with an apology to contributors.
I'm on PTO for the next couple weeks, so I hope you can all refrain from further attacks in my absence.
No, it's pretty abysmal. For the ones that do exist, as @ngompa mentioned they're often broken in pretty bad ways. For example, one common issue we hit in Fedora Asahi Remix is Electron-based applications flat out not working or crashing at random because of bugs in the Electron runtime that have long been resolved (but the flatpak is still using an ancient runtime). This ends up being a fairly major source of user reports, to the point that we've been actively discouraging folks from using flatpacks on Fedora Asahi Remix due to how bad the experience ends up being.
Is there a bug report against the Electron runtime?
Sorry, I meant "Electron runtime" in the sense of the bundled copy of Electron (which in turn bundles Chromium) in each and every flatpak, not in the sense of a common flatpak runtime (I don't think there is one for Electron? or at least I've never seen it). For Asahi specifically we track the ecosystem bugs at https://asahilinux.org/docs/sw/broken-software/
For the record: I wasn't at the meeting where the position statement was approved and, if I had been, I probably wouldn't have been in favour. I agree with most of the points in it. However, my long-standing position has been that Fedora should limit itself to a small and limited set of flatpaks. I don't think that we should be randomly replacing Flathub flatpaks - it creates an unpredictable experience for users and developers, and undermines the benefits of the flatpak ecosystem.
@yselkowitz Thanks a lot for your work on Fedora Flatpaks!
And in your article you precisely described the issues with Flathub that worry me the most and I talked about above:
Lack of source and build system provenance. Many projects which simply include .deb packages (which are of course not originally built on Flathub infrastructure, and are not always from Debian either) as “sources” and simply repack them. Some projects also include upstream-built individual binaries as “sources” and include them as well, even for dependencies which are not their own. So not everything shipped in Flathub is actually built on Flathub infrastructure (or other infrastructure trusted thereby), and not all sources are provided for the binaries being distributed. Lack of separation between FOSS, legally encumbered, and proprietary software. While proprietary software is (supposed to) be so tagged in flatpak definitions, and that tag is shown (with varying degrees of visibility) in the various interfaces, they are still in a single repository with no filtering. There is also no separation of legally encumbered software, which may affect users in various jurisdictions. Users who only want legally unencumbered FOSS need to carefully examine each application individually.
This makes it very hard for anybody who cares about security and freedom to use Flathub and I doubt these issues will ever be fixed. Therefore it is very nice to have an alternative in the form of Fedora Flatpaks and I actually would like to see them becoming the preferred way to install apps on Fedora with more apps available and more people working on them.
From my understanding, this is aligned with the benefits that I listed in the change proposal.
This position statement and any change proposals coming therefrom are an attack on my work and the work of everyone who is packaging desktop applications in Fedora.
The Change process in Fedora is here to create a place for important changes to be discussed and then voted on by FESCo. You are free to disagree with the change has it is proposed, but calling it an attack is not helpful.
Furthermore, this WG does not have the authority to decide what should be packaged in Fedora, only what is featured in the Workstation edition, and even then within the guidelines provided by FESCo
Yes, this is why this is a change proposal for the Atomic Desktops (which are maintained by the Atomic Desktop SIG) and I'm proposing that the Workstation WG consider joining it, but they don't have to. This change will be voted on by FESCo, like all other change proposals.
who already decided that Flathub content must not take priority over Fedora content.
This is not what this change is about. FESCo is also allowed to change what has been decided in the past. This is what the change process is about.
I don't think a lot of Fedora Flatpaks are Electrons apps (do we even have any?).
If a Flatpak is not available on Flathub or broken for a specific architecture and the Fedora Flatpak works, then it's a good argument for adding it to the filter, which is what that change is about.
I would support using Fedora Flatpaks if the Flathub version does not work well on aarch64 and Flathub maintainers were to refuses to accept a pull request to fix this, e.g. by updating to newer versions of Electron. aarch64 is strategic and must work.
ppc64le is not relevant to desktop users, except for a handful of brave souls using Talos workstations. We don't need to consider it.
s390x is not relevant to desktop users at all.
risc-v might be relevant in the near future, but it's too soon to expect Flathub to support it.
We have plenty of time before the change proposal deadline, so I'm fine with delaying a few weeks.
Lack of source and build system provenance. Many projects which simply include .deb packages (which are of course not originally built on Flathub infrastructure, and are not always from Debian either) as “sources” and simply repack them. Some projects also include upstream-built individual binaries as “sources” and include them as well, even for dependencies which are not their own. So not everything shipped in Flathub is actually built on Flathub infrastructure (or other infrastructure trusted thereby), and not all sources are provided for the binaries being distributed.
I'd like to see more information about this with respect to open source software packaged by Flathub. (Obviously this does not matter for proprietary software, so let's exclude that from consideration.) Packaging .deb files or binaries is unacceptable and Flathub ought to prohibit this if it does not do so already, and enforce the prohibition strictly. If Flathub fails to do so, then I think that would be adequate justification for Fedora to ship its own Flatpaks. But we should give Flathub ample opportunity to take action to fix this.
Lack of separation between FOSS, legally encumbered, and proprietary software. While proprietary software is (supposed to) be so tagged in flatpak definitions, and that tag is shown (with varying degrees of visibility) in the various interfaces, they are still in a single repository with no filtering. There is also no separation of legally encumbered software, which may affect users in various jurisdictions. Users who only want legally unencumbered FOSS need to carefully examine each application individually.
I don't think this is a real problem. Flathub does not have subsets for legally-encumbered software, but I don't care because this is a risk that Flathub accepts, and it's not at all relevant to end users. Flathub does have three subsets: verified, floss, and verified_floss. I'd say that's all Fedora needs.
verified
floss
verified_floss
@catanzaro Some examples:
Great examples, thanks. I suggest the Flathub community should formulate a response to (a) these specific examples, and (b) general policy of whether prebuilt binaries are allowed for open source software. This is normal and expected for proprietary software, but users will lose trust in Flathub if open source software is allowed to be distributed as prebuilt binaries. I would expect there to be a blanket prohibition on this, as in all major Linux distros.
Some open source projects simply find it easier to build the binaries in their own CI and repackage them for Flathub.
This is especially the case for Chromium or Electron-based projects. I don't believe Zed has any excuse though, we provide scripts to download Cargo dependencies in Flathub.
Blanket disallowing repackaging binaries from Flathub probably won't ever happen, unless we allow network filtering to have node and other network-reliant language package managers functioning in an offline build environment.
On Tue, Apr 8, 2025, 4:18 PM Michael Catanzaro pagure@pagure.io wrote:
catanzaro added a new comment to an issue you are following: Great examples, thanks. I suggest the Flathub community should formulate a response to (a) these specific examples, and (b) general policy of whether prebuilt binaries are allowed for open source software. This is normal and expected for proprietary software, but users will lose trust in Flathub if open source software is allowed to be distributed as prebuilt binaries. I would expect there to be a blanket prohibition on this, as in all major Linux distros. To reply, visit the link below or just reply to this email https://pagure.io/fedora-workstation/issue/463
catanzaro added a new comment to an issue you are following: Great examples, thanks. I suggest the Flathub community should formulate a response to (a) these specific examples, and (b) general policy of whether prebuilt binaries are allowed for open source software. This is normal and expected for proprietary software, but users will lose trust in Flathub if open source software is allowed to be distributed as prebuilt binaries. I would expect there to be a blanket prohibition on this, as in all major Linux distros.
Linux distros don't allow network during builds or prebuilt dependencies of any sort, and still manage to package things just fine.
I condemn prebuilt dependencies as abusive to users. If Flathub truly wishes to allow them, then I would go so far as to flip my position on Fedora Flatpaks vs. Flathub. Hopefully that's not the case.
I'm not going to put my own time and energy into discussing this aspect of Flathub. You can fix the previously listed apps to build from source yourself if you'd like to take that stance just as well.
On Tue, Apr 8, 2025, 4:39 PM Michael Catanzaro pagure@pagure.io wrote:
catanzaro added a new comment to an issue you are following: `` Linux distros don't allow network during builds or prebuilt dependencies of any sort, and still manage to package things just fine. I condemn prebuilt dependencies as abusive to users. If Flathub truly wishes to allow them, then I would go so far as to flip my position on Fedora Flatpaks vs. Flathub. Hopefully that's not the case. `` To reply, visit the link below or just reply to this email https://pagure.io/fedora-workstation/issue/463
catanzaro added a new comment to an issue you are following: `` Linux distros don't allow network during builds or prebuilt dependencies of any sort, and still manage to package things just fine.
I condemn prebuilt dependencies as abusive to users. If Flathub truly wishes to allow them, then I would go so far as to flip my position on Fedora Flatpaks vs. Flathub. Hopefully that's not the case. ``
https://github.com/search?q=org%3Aflathub+%22.deb%22+AND+%28path%3A*.json+OR+path%3A*.yaml+OR+path%3A*.yml%29&type=code gives you a rough idea of how many are deb repackages (note that some of these are false positives and some are false negatives). There's also a fair number that repackage tarballs or other artifacts (for example, https://github.com/flathub/org.zotero.Zotero/blob/master/org.zotero.Zotero.yaml).
Perhaps Flathub could introduce a new category for FOSS apps that are built from source on their infrastructure, and a warning could be displayed for any app that doesn't do this.
It is true that some apps cannot be easily built from source (Electron/TypeScript usually). I wouldn't mind their presence on Flathub as long as there is a way to filter them out. I would like to treat them in the same way as I treat proprietary apps: a huge security/privacy risk.
At the same time everything that can be built from source, should be built from source (e.g Zed). As a user, I don't want to manually check the manifest of every app to verify this. Adding a new category would encourage devs to do it the right way so that their app gets a nice "Built from source" status.
Well that's a useful starting point, but we also need to filter out the proprietary software, since of course it's expected that proprietary software is not built from source.
Perhaps Flathub could introduce a new category for FOSS apps that are built from source on their infrastructure, and a warning could be displayed for any app that doesn't do this. It is true that some apps cannot be easily built from source (Electron/TypeScript usually). I wouldn't mind their presence on Flathub as long as there is a way to filter them out. I would like to treat them in the same way as I treat proprietary apps: a huge security/privacy risk. At the same time everything that can be built from source, should be built from source (e.g Zed). As a user, I don't want to manually check the manifest of every app to verify this. Adding a new category would encourage devs to do it the right way so that their app gets a nice "Built from source" status.
This seems like a very reasonable proposal. I had the same idea and have suggested it to the Flathub developers. Flathub is not safe in its current form, and if nothing changes then we should remove it entirely; repos gated behind the enable third-party repos dialog must at least be safe. Fedora should only enable a subset of Flathub that we can be confident is actually built from source. This is an essential principle and it's more important than all other considerations discussed in this thread; Fedora users must be confident that open source software is actually built from its source code in safe infrastructure.
I did not take this problem seriously enough when we were discussing the position statement.
I will propose the following change for the Atomic Desktops for Fedora 43: https://fedoraproject.org/wiki/Changes/FilterFedoraFlatpaksAtomicDesktops If the Workstation Working Group is interested, then we could make this a more broadly scoped change instead of having it focused on the Atomic Desktops only. Feedback welcomed.
I'm still hopeful that this is the path forward, but I think we should wait and see whether Flathub improves things first. I would make this change for atomic distros and Workstation at the same time, but only if we can gain improved confidence in the security of Flathub's builds.
Log in to comment on this ticket.