I feel like OP missed an opportunity to title this post “Fedora Flatpaks Fall Flat”
Great article, BTW
Great article, BTW
I disagree, the headline is clickbaity and implies that there is some ongoing conflict. The fact that the Fedora flatpak package maintainer pushed an update marking it EOL, with “The Fedora Flatpak build of obs-studio may have limited functionality compared to other sources. Please do not report bugs to the OBS Studio project about this build.” in the
end-of-lifemetadata field the day before this article was written is not mentioned until the second-to-last sentence of it. (And the OBS maintainer has since said “For the moment, the EOL notice is sufficient enough to distance ourselves from the package that a full rebrand is not necessary at this time, as we would rather you focus efforts on the long-term goal and understand what that is.”)The article also doesn’t answer lots of questions such as:
- Why is the official OBS flatpak using an EOL’d runtime?
- Why did Fedora bother to maintain both their own flatpak and an RPM package of OBS?
- What (and why) are the problems (or missing functionality) in the Fedora Flatpak, anyway? (there is some discussion of that here… but it’s still not clear to me)
- What is the expected user experience going to be for users who have the Fedora flatpak installed, now that it is marked EOL? Will it be obvious to them that they can/should use the flathub version, or will the EOL’d package in the Fedora flatpak repo continue to “outweigh” it?
Note again that OBS’s official flathub flatpak is also marked EOL currently, due to depending on an EOL runtime. Also, from the discussion here it is clear that simply removing the package (as the OBS dev actually requested) instead of marking it EOL (as they did) would leave current users continuing to use it and unwittingly missing all future updates. (I think that may also be the outcome of marking it EOL too? it seems like flatpak maybe needs to get some way to signal to users that they should uninstall an EOL package at update time, and/or inform them of a different package which replaces one they have installed.)
TLDR: this is all a mess, but, contrary to what the article might lead people to believe, the OBS devs and Fedora devs appear to be working together in good faith to do the best thing for their users. The legal threat (which was just in an issue comment, not sent formally by lawyers) was only made because Fedora was initially non-responsive, but they became responsive prior to this article being written.
I can confirm, I really missed the opportunity
You can edit the title…
IT’S OVER, MAN. YOU HAVE TO LET IT GO!!!
The issue is that they are pushing their own version of flatpaks, some of which are broken, instead of contributing to flat hub and making that the default.
That wouldn’t work. Flathub and Fedora Flatpaks have different goals.
Fedora Flatpaks must meet legal requirement set by Fedora, so no proprietary or patented software.
Flathub also encourages upstream to maintain their packages. But upstream may not meet the security requirements set by Fedora. Fedora has much stricter packaging guidelines which don’t permit vendored dependencies.
That honestly doesn’t sound like a bad mission, but it seems like there’s a couple other requirements they should impose on their mission and then there wouldn’t be any controversy.
They should require that their package works as well as the upstream, and, in the even that it doesn’t, they need to be very blatant and open that this is a downstream package, and support for it will only be provided by Fedora Flatpaks, and that you may have better results with the official packages.
The primary issues in this case is that it doesn’t work, and it’s not been clear to users who to ask for help.
I’m sorry, but you’ve completely missed either the point, or how it works.
Flathub is really the problem here for not properly verifying package owners/maintainers and allowing them to moderate other versions of their work.
There honestly just needs to finally be a way to sort official packages from community packages. Right now it’s a mess. Fedora should just take theirs down.
Confidentally incorrect.
Flathub has nothing to do with this
As someone who works with multiple projects who have had to beg and plead to get broken packages taken down, I can confidently assert that it is.
They’ve gotten too popular too fast, and dozens of projects have had similar experiences to OBS.
Some issues we’ve dealth with in the past year:
- unmaintained community package which included libraries that made our package vulnerable and was tripping up static scanners
- one package unpublished due to a complaint from a completely unrelated person
- spammed and suspect versions of our packages being published with shady blobs that aren’t part of our project
There’s plenty more. There just isn’t any kind of moderation, and there needs to be. Regardless of their original intent, it’s now become too big to just let go. Similar things have happened over the years with almost every maintained public package repository: gems, npm, pypi…etc.
Now it’s time for the Flathub folks to step up and do some moderation to prevent worse things from happening. The minimum they could do is add a flag for official packages that are confirmed to be from the proper sources, but that requires a bit of effort on their part.
This isn’t about Flathub. The problem is that Fedora has their own flatpak repo and the packages there take priority over the properly-maintained ones in FlatHub, per OBS.
Not that what you’ve mentioned is wrong, but in this comment section that’s a different topic than what we’re discussing.
Why did Fedora make their packages take priority? Is it because the priority is otherwise random and if you don’t have a priority set, that leads to the issue they mentioned? Because if so, that sounds like a reasonable action by Fedora and like the real culprit is Flathub.
They put their repo first on the list. Packages will default to Fedora’s repo if available. You may specify which version you want, if you both know that it’s happening and know that the package you want in particular is available at both.
I really again do not know how this could possibly be the fault of another repository. Fedora is making decisions for ther distro that circumvent FlatHub, this is not FlatHub’s fault.
They put their repo first on the list.
Right. And are we talking about the list for OBS or of repos in general? I doubt Fedora sets the priority on a package level. And if they don’t, and if there are some other packages in Flathub that are problematic, then it makes sense to prioritize their own repo over them.
That said, if those problematic packages come from other repositories, or if not but there’s another alternative to putting their repo first that would have prevented unofficial builds from showing up first, but wouldn’t have deprioritized official, verified ones like OBS, then it’s a different story. I haven’t maintained a package on Flathub like the original commenter you replied to but I don’t get the impression that that’s the case.
Ah I’m glad to see the situation seems to have cooled a little.
See this comment and the three following, as well as this one and the two following. I think they can now work it out between the projects reasonably.
PS: This more fundamental proposal for Fedora Workstation that started from the OBS packaging issue is also interesting to read. It seems they are looking to make more limited / focused use of their own Flatpak remote in the future since some old assumptions regarding Flatpaks and Flathub don’t hold so well anymore.
What is the lesson we can learn here as stated by the author of the post?
A messy situation but hopefully one some lessons can be learned from.
There is no info why packaging failed. I can’t draw any obvious lesson from this post
The lesson is that Fedora Flatpak Repo needs to fuck off. It’s an anti-pattern to have an obscure flatpak repo with software that is packaged differently from everything else.
The entire point of flatpaks was to have a universal packaging format that upstream devs could make themselves, and Fedora is completely undermining it.
And Fedora Flatpaks are universal, they work on any distros.
Flatpak by design allows you to install Flatpaks from multiple stores. The fact that snap only allows one store is a common criticism of snap.
Fedora Flatpaks were created because Fedora has strict guidelines for packages. They must be FOSS, they must not included patented software, and they need to be secure.
Flathub allows proprietary and patented software, so not all Flathub packages could be preinstalled. And if a Flathub package was preinstalled, it could add proprietary or patented bits without Fedora having a say.
Flathub packages are also allowed to use EOL runtimes and include vendored dependencies that have security issues. Fedora does not want this. Fedora Flatpaks are built entirely from Fedora RPMs so they get security updates from Fedora repos.
They work on other distros… if they work at all. If those “strict guidelines” are resulting in flatpaks like OBS and Bottles, which are broken and the devs have tried to get them to stop shipping, then I’ll pass on Fedora flatpaks.
I dont criticize Flatpaks for allowing alternative packaging sources. I criticize Fedora for sneakily (whether intentionally sneaky or not) setting their broken flatpak repo as the default, leading to a bunch of confusion by Fedora users that don’t know they’re actually using different, sometimes broken, packages from everyone else.
The uBlue downstreams of Fedora know this, and they have the decency to present the user with that information upon installation. So thankfully, their users don’t end up wasting their time with problems that Fedora introduced.
“strict guidelines” are resulting in flatpaks like OBS and Bottles, which are broken and the devs have tried to get them to stop shipping, then I’ll pass on Fedora flatpaks
That’s fine.
I criticize Fedora for sneakily (whether intentionally sneaky or not) setting their broken flatpak repo as the default
It’s not sneakily. Fedora Flatpaks do not have verified badges and in Gnome Software, they show “[Flatpak Icon] Fedora Linux” right under the install button.
Is this system perfect? No. For example, it stills shows “Mozilla Corporation”, but note that this issue also affects Flathub. That line is about the app creator, not publisher.
leading to a bunch of confusion by Fedora users that don’t know they’re actually using different, sometimes broken, packages from everyone else.
Most people get their packages from their distros repos. Arch, Linux Mint, Pop!_OS all default to distro repos. The latter two include Flathub, but still prefer debs by default. So most people are using unofficial packages by default that are different from what everyone else is using.
As for users feeling “tricked”? That’s a difficult thing to say. I would like to say that users should at least know something about the distro they are choosing (ie Ubuntu users should know about snap; Fedora/Debian users should know about their stances on FOSS, security, and patents; Arch users should know its a DIY distro). But I was once a new user and I remember using Ubuntu for months before learning that their packages aren’t official and about how their repo freezes work.
The situation could certainly be improved. Fedora could show a slide in Gnome’s Tour screen informing them about Fedora defaults to their own packages not supported by upstream and their stances on FOSS.
I don’t disagree with most of that, but none of what you said actually addresses the problem. The problem is that there are functionally two (notable) flatpak repositories, but one of those is going against the will of the upstream software devs and shipping broken software that they have asked them to stop packaging. And Fedora users are getting the broken flathub repository as the default, without really having reason to suspect that their “flathub store” would ever trick them into installing from a different source. The “verified” badge, especially the lack thereof, does not address that.
As for users feeling “tricked”? That’s a difficult thing to say. I would like to say that users should at least know something about the distro they are choosing (ie Ubuntu users should know about snap; Fedora/Debian users should know about their stances on FOSS, security, and patents; Arch users should know its a DIY distro).
You can RTFM someone all day, but if you actually want Linux to be adopted by more people, you need to reduce the anti-patterns. Snaps are generally known about because they are infamous for also breaking packages. And they’re still major footguns when people are recommending Ubuntu to people that are new to Linux, who are the least likely to know that their
aptpackage installations are going to be installing differently-packaged software that has its own set of problems. If we get to a point where Flatpaks have a similar problem to Snaps, we’ve taken a wrong turn, and it will only hurt Linux adoption.
Honestly, that sounds great.
My biggest problem with Flatpak is that Flathub has all sorts of weird crap, and depending on your UI it’s not always easy to tell what’s official and what’s just from some rando. I don’t want a repo full of “unverified” packages to be a first-class citizen in my distro.
Distros can and should curate packages. That’s half the point of a distro.
And yes, the idea of packaging dependencies in their own isolated container per-app comes with real downsides: I can’t simply patch a library once at the system level.
I’m running a Fedora derivative and I wasn’t even aware of this option. I’m going to look into it now because it sounds better than Flathub.
Why don’t you like fedora flatpaks?
Among other reasons, Fedora ensure that apps get a flatpak. Imagine there was no official flatpak, fedora would’ve made one. Just like fedora ensures that there are native ways to install it via dnf. On atomic distros, you want to use flatpaks very often. Hence it makes sense to package apps via flatpak.
Fedora ensures that there is not additional code in the app kind of like fdroid on phones.
Anyone can make flatpaks, not just the main dev.
I answered most of this in the other thread, but I am aware that anyone can make flatpaks. What I meant is that flatpaks were supposed to make it easier for devs to get their software to end users by allowing them to not have to worry about distro-specific packaging requirements or formats.
But when someone else takes it upon themselves to make broken flatpaks, ones that you’ve requested they stop doing, now they’re making things worse for everyone involved and should be considered a hostile fork and treated as such.
It reads as if fedora wanted to created a broke package. As if it was on purpose to annoy everyone. Do you think that was their intention?
The OBS and Bottles packages have been broken for a long time. Long enough that both upstream projects asked them to stop many months ago. They don’t get to pretend it was a mistake. This isn’t just another case of a minor packaging bug getting to users. They are packaging the software incorrectly.
Not OP, but for me the issue is if you want to override the default and make it opt-out, especially sine the opt-out process isn’t that well documented, then you should realize that support is a necessary part of that process and fix problems as they arise rather than resorting to name calling and hostile behavior when something you published is broken. It’s a responsibility of taking on that kind of project. Either that or make it explicitly opt-in and give users a warning like with beta version opt-in notifications that the packages are not official and issues may not be fixed as quickly as the official releases.
Obviously, the best solution is that the gets settled out-of-court. However, Fedora has had a long time to listen to the OBS devs’ request to stop packaging broken software, so maybe they won’t listen to reason.
Fedora needs to get their heads out of their asses and kill the Fedora Flatpak repo.
Totally forget that I still was in fedora’s flatpak repo until the news dropped. Took the opportunity to remove and replace it with flathub.
Is there any merit to the claim OBS is using an end-of-life (EOL) runtime and that this is a very bad thing for security?
OBS continued using the EOL runtime because of Qt regressions introduced in the updated KDE runtime. The OBS team decided the security risk of sticking to the EOL runtime was small, so they didn’t update.
But that still does mean that users were no longer receiving security updates. Ideally, OBS should have moved to the standard Freedesktop runtime and vendored in the older Qt dependency. That way, the they would still be receiving security updates for everything in the Freedesktop runtime. Then once the regressions were fixed, they could move to the updated KDE runtime and remove the vendored Qt dependency.
Overall, the risk OBS had was small. But it demonstrates a larger issue with Flathub, which is that they don’t take security as seriously as Fedora. There are hundreds of flatpaks in Flathub that haven’t been updated in years, using EOL runtimes and vendored dependencies that get no updates.
It’s important to acknowledge that nothing is completely secure.
I didn’t know this was an issue for OBS because I’m not experiencing any problems nor am I seeing anyone else.
I think you might find this comment by one of the OBS upstream devs interesting:
https://pagure.io/fedora-workstation/issue/463#comment-955899
Fedora’s opinion seems to be that upgrading is always the right choice, which we disagree with.
Ugh, I’m glad people are willing to fight back against these kinds of assertions.
Regardless of who is right, facilitating and encouraging this kind of discourse is how we end up with better software for everyone.
thanks!
Just gonna leave this here…
It’s not that hard to actually follow XDG specifications instead of hardcoding paths.
Which flatpak itself doesn’t, btw.
$HOME/.varfor flatpaks is hardcoded, no answer in the issue tracker so far, to the proposal of using the usualflatpak_xyz_dirvariable to change the path.
inb4 Iceweasel
lol. so I guess fedora is pushing flatpacks now? I know Ubuntu was pushing snap, so I guess fedora followed suite with a different standard. yay.
thankfully arch isn’t getting into this nonsense
Worse than that, the issue the article states isn’t that it’s a flat pack, it’s that fedora is pushing their rebuilt flat pack of obs that’s buggy instead of the official obs one from flat hub that works, and then the obs project is getting bug reports for a third party distribution that’s broken.
Because fedora isn’t just pushing flat packs, they’re pushing made by fedora versions of them instead of the official builds from the maintainers.
Great explanation.
If I were the OBS devs, I’d make a clear indication on their website when reporting bugs that the fedora version of OBS is unsupported for, well, the reasons they don’t support it.
It seems way more effective than threatening legal repercussions.
It doesn’t mean they are pushing flatpaks, but rather for whatever reason they decided to package their own flatpaks.
Flatpak can support different repos, so of course fedora can host its own. The strange bit is why bother repackaging and hosting software that is already packaged by the project itself on flathub?
One argument might me the security risk of poorly packaged flatpaks relying on eol of dependencies. Fedora may feel it is better to have a version that it packages in line with what it packages in its own repos?
I have some sympathy for that position. But it makes sense that it is annoying OBS when it is causing confusion if its a broken or poorly built repackags, and worse it sounds like things got very petty fast. I think OBS’s request that fedora flag this up as being different from the flathub version wasn’t unreasonable - but not sure what went down for it to get to thepoint of threatening legal action under misuse of the branding.
Fedora probably should make it clearer to its users what the Fedora Flatpak repo is for.
Fedora already has two “warnings” when it comes to their own packages.
First, Gnome Software shows a verified badge for all Flatpaks that are maintained by upstream. The Fedora Flatpak does not have this badge.
Second, when installing a Fedora Flatpak, the label “Fedora Flatpak” shows right under the install button
Sure, this isn’t perfect. Non-technical users may not understand what these mean. But it’s not like Fedora is intentionally trying to mislead users.
Having distro-specific flatpaks really seems to be defeating the whole purpose
It’s not distro specific. Fedora Flatpaks are just built from Fedora RPMs, but they work on all distros.
If you care about FOSS spirit, security, and a higher packaging standard, then Fedora Flatpaks may be of interest.
If you want a package that just works, then Flathub may be of interest. But those packages may be using EOL runtimes and may include vendored dependencies that have security issues.
I prefer flatpaks that work.
And that’s a perfectly fine position to have. I get most of my apps from Flathub.
I also think that Fedora Flatpaks should be allowed to exist. And most of them work without issues. They just don’t get as much testing as Flathub since the user base is smaller.
And that’s a very good answer to a provocative message.
Fedora has always been one of the flatpak friendly distros.
No, it’s not like snap. Fedora is not removing RPMs and replacing them with flatpaks. It just defaults to flatpaks. Fedora Flatpaks are built entirely from existing RPMs.
thankfully arch isn’t getting into this nonsense
🙌
Ubuntu was pushing snap,
interesting… ive not seen anything regarding snaps in mint… flatpak is the other option in the software manager
Mint explicitly goes out of its way to disable snap in favour of flatpaks.
https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html
The Mint team removed snap intentionally and explain their reasons here: https://blog.linuxmint.com/?p=3906
cool, thanks for the info!
And that’s the #1 reason to use Mint over Ubuntu!
Snaps make a little more sense in servers since you can package CLI stuff in snaps, but not in flatpaks. For GUI apps, it’s “fine” but it doesn’t solve new problems, and the way Canonical has migrated apt packages to snaps is aggressive and error-prone.
very interesting. i use mint as a default workstation and i put it on a lot of older machines for older people as a windows upgrade. it just seems to work except for a very occasional audio issue.
