Just Delete The Fedora Flatpak Repo Already
If you're downloading a Flatpak, you're probably downloading it from Flathub. This is the upstream default of the Flatpak project, and for the most part, distros don't change this because there's really not a reason to. This is the main place that people upload Flatpaks to. However, it's not the only Flatpak repo. Unlike Snap, anybody can go and host a store if they want to.
It's just been pretty centralized on Flathub. So there are things like the beta repos. There are some projects that have personal repos like Gnome and KDE. And of course, the most notable, Fedora Flatpaks.
This, for better or worse, depending on who you ask, is a Flatpak repo made by the Fedora project, built off of their existing RPM infrastructure they use for their regular repo packages. Now, this being a Flatpak repo means that anybody can go and use this. So if you want to use this on Ubuntu or Arch, you can go and do so. But the main people who might go and use this are Fedora people, because this is the only place where it's actually enabled by default. Now, the improvements claimed by this project is they are more tested and more robust than the packages available by random third-party maintainers on Flathub. And I'm sure in some cases, that is going through the case.
However, the reality of the situation is not that simple, especially when we start looking at those first-party Flatpaks available on Flathub from the likes of Bottles or OBS or a bunch of others that are available, where the developers of the project are the maintainers of the package, and they have a very deep understanding of how the software should be packaged correctly to make sure it's actually doing the thing the software should be doing. Now, as of 2023, Fedora did make it considerably easier to have Flathub enabled on Fedora. Previously, you'd have to go and run the command directly from the Flatpak CLI, and yeah, you can do that, it's fine, but it's still kind of annoying to have to go and do that to get the proper Flathub working. But they didn't get rid of Fedora Flatpak, and they didn't even change the fact that Fedora Flatpak was the default Flatpak repo being used. And as of a few days ago, this issue was opened.
Deprioritize Fedora Flatpaks and prioritized Flathub in Gnome software. As always, please don't just go and leave random comments on here if you have nothing else to add. Leave those in my comment section.
Let's go on. Currently, this is still open, and the response is quite mixed, in fact. People who are in favor of Fedora Flatpak are very in favor of Fedora Flatpak.
And people who just don't want Fedora to do weird things, well, you'll see. 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 precedent in Gnome software, Fedora Flatpaks, and then RPMs, and then Flathub is the last one. Now, when it comes to OBS specifically, on Linux, there are two correct ways to install it. Only two. Everything else you can do if you want to, but it's going to be a more limited version of OBS.
There is the PPA on Ubuntu, or there is the Flatpak. That is all. Nothing else. Anything else that's out there, whether it be a snap, whether it be the package on Arch, this is going to have certain features missing because of some API key issues and a couple other things like that. If you want OBS working correctly, use one of these methods. It's not as extreme for a lot of other software, but still keep it in mind.
If the developers have a way to install the software, I generally recommend using the thing they suggest, unless it's just not available for you. Unfortunately, Fedora Flatpacks have been a significant source of quality problems and have been, frankly, generally unsuccessful. Fedora Flatpacks are not well-tested and users who understand what they are generally do not want to use them. They want to use the higher quality Flatpacks created by upstream instead, but most users don't even realize they're getting a Flatpak from Fedora rather than from upstream, which can result in considerable confusion. Now, I know people like Fedora a lot more than Ubuntu and Flatpacks a lot more than Snaps, but this is the exact same thing that Ubuntu does with Snaps, where you think you're installing one package and you get a completely different package.
If you install Firefox with apt on Ubuntu, it installs the Snap. If you install a package that is in both Fedora Flatpacks and Flathub, you'll get the Fedora Flatpak. Yes, they're both still Flatpacks.
Yes, it's not as bad, but it's still not something you should be doing. Now, Fedora is a bit more open about doing that. You can relatively easily see it, but if you're a new user, I can understand why you wouldn't know what to be looking for. I want to completely change the precedence in GNOME software to Flathub, Fedora Flatpacks, Fedora RPMs. Now, if you ask me, I would delete this one entirely.
Just delete Fedora Flatpacks. Bad idea. Just doesn't need to exist.
But that's not going to happen. So I do agree this is a better ordering. However, Fesco approved inclusion of Flathub on the condition that it is the lowest priority source from that change proposal. The thing I mentioned a little bit earlier, this is the actual link directing you to the actual details of the change. So we would go through a change proposal process to propose changing this. So allow it to be Flathub up the front.
Now, you might think this is a lot of bureaucracy to make a change happen. And yes, it is. However, I do like the way Fedora handles things because there is actually a log of changes being made. It's not just some random person makes a major change and nobody knows what's happening.
But there are some alternatives. Alternative one, Fedora RPMs, then Fedora Flatpacks, and then Flathubs. So take your regular distro packages and make those the top precedents. But this is not desirable because it underestimates the importance of Flatpak sandboxing and prevents us from ever reaching desktop security goals. I'll write some blog posts about this eventually.
Also, yeah, they just generally want to move away from RPMs over to solutions like this, whether it's Fedora Flatpacks or Flathub. Not really super relevant, but they want to go to one of those. Alternative two, just remove Fedora Flatpak remote by default.
I think just delete it from existence entirety, but hey, again, that's just me. However, we really do need Fedora Flatpacks for at least GNOME core applications to implement this right here. So this would not be an ideal outcome, but perhaps we create separate Flatpak remotes for pre-installed Flatpacks versus everything else.
I don't see any reason why they need Fedora Flatpak to do that. like the entirety of Fedora Flatpak. You, yeah, I don't know why. Now being Fedora, you probably spotted this name right here. Neal Gompa is the first one to respond. Alternative three, make it user configurable like Plasma Discover does.
And this is good. Yes, it should be user configurable, but it's not really relevant to the issue at hand here because this is discussing the default, not whether it should be configurable. It should also be, but what should it be out of the box? Moving on to the next comment. I disagree with the assertions that Fedora Flatpacks have been a significant source of quality problems and that Flathead Flatpacks 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. This is when the Bottles devs did not want Fedora to be packaging the software because they consistently package it wrong.
It's consistently buggy and they don't want to deal with people reporting issues to them. So Bottles devs were like, okay, we're just going to break the package if it's not in the Flatpak. Get over it.
If software is false, then by definition, we must have the right to redistribute it as we please and upstreams cannot restrict that and remain false. This has never been about what you have the right to do. You have the right to make a package. You have the right to make a package that completely misrepresents the software and makes it look super buggy unless they have, you know, trademarks of the name, which case, yeah, you can't do that and you have to like change the name, all the fun stuff.
But this is not about what you have the right to do. It's what you should be doing. Should every single distro go and package that software? No? That's my stance at least. If there is a one definitive package, why duplicate that work? 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.,
AppImage, Snap, things like that, 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. Again, it has nothing to do with rights or power. You can do whatever you want. That's fine.
No one's stopping you doing so. They might make it harder to do, but you have the right to do it. But if things are being done upstream, why make a package on every distro? Just answer that question. It might make sense for something like GCC, but if we're dealing with something like bottles or OBS, if the developers have a package, why should 10 other distros make identical packages with different build scripts? Answer that question.
In my opinion, 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 non-existent. That's not to say there isn't useful content there, but priority should definitely be given to our own builds. In response to that, here's an example of a Fedora Flatpak specific problem. This is only in their build. Fractal Flatpak does not show images. A bug in the RPM packaging meant the runtime image load's dependency of Fractal was missing from the specs, possibly due to the package and not looking closely enough at dependency changes when handling a version bump.
This issue probably wasn't found during testing because all the testers had Loupe installed on their system, which caused the image loaders to be available. However, the Fedora Flatpak build of Fractal installed as 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. And that would be fine if when users had a bug, they went to the distro to complain. But that's not what they do, especially in the cases where they think they are installing the Flatpak made by the developers.
So they went to the developers and basically they said go away, go report it to Fedora. This is not our problem. We didn't cause this. Honestly, if they were a little bit meaner and I've seen this before, they would tell you to go install a better distro.
Now there were also some other alternative orderings, starting with Verified Flathub, then Fedora Flatpak, then Fedora RPM, and then Unverified Flathub. Other one, Verified Flathub, Fedora Flatpak, Unverified Flathub, and Fedora RPM. Honestly, I think this is just excessively confusing. Just, just, just remove this one. Just, just, just get rid of this and everything gets so much easier. So the main argument here comes down to not duplicating packages versus specialized package knowledge.
Is it better to have just the package available for the project that's made by one person or is there some additional value that having a Fedora specific package adds to the equation? Even though it's both just a Flatpak, is Fedora doing anything better with the handling of the software that it justifies its existence? Here is someone very against Fedora Flatpaks. 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 gave 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 that 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 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 verfied 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. This is the main reason why developers are so in favor of Flatpaks and of app images and of snaps in the cases where they like snaps because they know the environment the software is running in. They know the dependencies it's going to have.
They know exactly what patches are in the software. And they know exactly what version it's going to be. So they don't have a case where say Ubuntu for example cherry picks some random patches and someone reports a bug to the project but that feature's not in the project because Ubuntu decided to just add a feature that wasn't ready yet. By that logic an RPM shouldn't exist if there's something in FlatHub. Yes.
Yes. If it's made by the developers 100%. And then from Neal 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 upstream if at all possible.
The more effort spent on improving upstream development the less effort spent on ensuring unofficial packaging doesn't break and the better upstream software becomes. Now it's kind of weird for me to see Neil arguing against this because he's quite a big advocate for contributing directly upstream where possible. So I know he is a fan of Fedora and wants to do things on the Fedora side and I've spoken to him about this before and he thinks that packages downstream do add a lot of value but I don't know I just can't find myself agreeing with that perspective.
And I kind of understand why this issue exists because this is a big change in the Linux development model where traditionally the upstream developers they make the software. So KD developers they make KDE. OBS make OBS.
Bottles they make bottles. And then the downstream distros your Ubuntu's Gentoos Archs things like that they make the packages and then hopefully contribute code back upstream help with bug fixes help with bug reports but in recent years there has been this shift in packaging where in a lot of cases the upstream developer is doing both the development of the software and the maintainership of the package and then the downstream in many cases still have their own package in their repos but also serve the role of testing both of the packages where they're testing their own package but also the package made by the upstream developers. I understand why downstreams want to keep packaging because in a lot of cases they think they have a deeper understanding of packaging of the software and just packaging in general than the developers of the upstream project but the upstreams want to go this route because they can choose exactly how a software is packaged they know exactly what is in that package and they can do a much better job at fixing bugs because they don't have all of these weird different dependencies that every single distro is changing out. Now I don't see this as a zero sum game but I do think the role of the distro is shifting and distro developers can try to fight this but I don't think they're going to win.
What I see happening in the long run is the distro is going to focus more on the core system packages on the desktop on things like GCC and things like that rather than packaging every single user application themselves and then the upstream developers they are going to package the software they want to package and it's just going to be a much better experience for both the developers and the users because they know the software is going to work and the upstream developers know if the software isn't working they know the environment it's running in but right now we're in the middle of a transitionary stage where people aren't really used to this model yet and sort of want to hold on to the way that things have always worked and I'm sure some distros are going to do so but I don't see that being the case in the long run at least for major distros obviously for things like Arch you know Arch was going to do their thing but I do think that even if the approach of packaging using snap was wrong Ubuntu is onto something with the way they're doing things but what do you think I'm sure that final take is going to bring some interesting comments to say the least put them down below feed the algorithm so if you like the video go like the video and if you really like the video and you want to become one of these amazing people over here Patreon, SubscribeStar Liberapay linked in the description down below that's going to be it for me and right now this problem's still not solved nothing has been dealt with but I'm kind of curious to see how the Fedora Flatpak situation actually turns out
2025-02-09 21:19
