Fedora threatened with legal action from OBS Studio due to their Flatpak packaging
-
This isn't about Flathub. The problem is that Fedora has their own 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.
-
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?
-
IT'S OVER, MAN. YOU HAVE TO LET IT GO!!!!
-
Is there any merit to the claim OBS is using a end-of-life (EOL) and that this is a very bad thing for security?
-
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.
-
“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.
-
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.
-
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 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. -
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. -
And that's a very good answer to a provocative message.
-
I think you might find this comment by one of the OBS upstream devs interesting:
https://pagure.io/fedora-workstation/issue/463#comment-955899
-
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.
-
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 are the problems with 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.
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.
-
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.
-
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.
-
thankfully arch isn’t getting into this nonsense
-
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.
-
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.
