OBS-tacle course: Fedora and Flathub's Flatpak fiasco sparks repo rumble

Dispute settled, but not the causes

A clash over different Flatpak-packaged versions of OBS Studio highlights problems with distro-maintained software repositories versus external ones.

The dispute between the Fedora Project and the collective behind OBS Studio has been settled. For now, peace has been restored, but the situation has shed light on several problematic aspects of distro-independent packaging systems. While this fight is over, the underlying issues are still very much alive.

OBS Studio – the initialism stands for Open Broadcaster Software – is a popular cross-platform open source package for livestreamers. Popular enough that we were reporting squabbles over its trademark nearly four years ago now. Its development team maintains versions for Windows, macOS, and Linux, and the official Linux package is a Flatpak (although other packages are available). That official Flatpak package is hosted on Flathub. This is a significant piece of software – for instance, as we noted in our coverage of Zorin OS 16.2, OBS Studio is one of the Flatpak apps bundled with this distro's premium, paid-for edition.

The original issue arose because this isn't the only available Flatpak of OBS Studio. The Fedora Project also hosts its own, separate, independent Flatpak repository, as Fedora Magazine explained in 2021 and whose differences it elaborated in 2022. Some of the packages in Flathub are also in Fedora's Flatpak repo – such as OBS Studio. Flatpak allows for this, and enables repos to be assigned priorities in case of clashing names – so if there are two packages with the same name in two different repos, one takes precedence.

One of the snags with this is a known issue: Fedora sets its own repo to have priority over Flathub, and it's not that easy to change the priorities. Users need to type a long gsettings command in the terminal. Depending on a particular machine's desktop environment and the app store-style front end that they're using, they may be able to choose which channel an app comes from, but this isn't obvious to non-technical users.

For example, OBS Studio users found features missing or simply not working, along with other issues. These seemed to be due to Fedora's Flatpak, rather than the official one – but the users didn't know that they weren't using the official package. Weeks after reporting the issue, it was still unresolved, to the point that maintainer Joel Bethke filed a strongly worded note requesting removal on trademark grounds.

Things are now happening. The Fedora Flatpak has been marked for retirement. There are also discussions about prioritizing Flathub, and it's caused an older discussion about prioritizing verified Flatpaks to resurface.

The problem of verified versus unverified apps is emphatically not limited to Fedora. When we looked at Linux Mint 22, we noted that by default its Software Manager only shows Flathub Flatpaks that are verified, meaning packaged by their creators. The problem is that restricting Flathub to only verified packages dramatically reduces the range of apps on offer. For example, despite the official-looking name in its URL – com.google.Chrome – Flathub's Google Chrome package is unverified. Its description does say:

NOTE: This wrapper is not verified by, affiliated with, or supported by Google.

Sadly, in real life, most people never read the small print.

The problem of official verified cross-distro packages isn't limited to Flathub either. Nearly a year ago, we reported on the problem of scam apps in Canonical's snap store. Canonical's response was to switch to manual validation of app names.

In a recent video interview, Fedora's Matthew Miller, who is at least for now the project lead, expressed his reservations with Flathub's validation process. The response has been an angry backlash, and a blog post detailing Flathub's safety approach from former Elementary OS developer Cassidy James Blaede, who now works on Endless OS – a distro that puts Flatpak front and center.

Youtube Video

One of the reasons that cross-distro packaging projects exist at all is to make it easier to provide newer versions of software, bypassing distributions' relatively slow release cycles. For instance, as we described when Mozilla started publishing official Debian packages, by packaging Firefox as a snap, Canonical can put out one package that runs on all versions of Ubuntu that are currently in support. As a new version of Firefox appears about once a month but there are only two Ubuntu releases a year, this saves the company a lot of effort and keeps the browser more current. To do this with .deb packages, Canonical would have to maintain separate packages – and all their dependencies – for the seven different versions of Ubuntu currently in support. For comparable reasons, Red Hat dropped native LibreOffice packages from RHEL, relegating it to Flatpak – althoughm as we reported, natively packaged Firefox ESR is returning to CentOS Stream.

It's not just about finding ways to reconcile different release schedules. Cross-distro packaging schemes make it easier for developers to support more distros, and help keep third-party additional packages updated. But any move that helps legitimate app developers and vendors equally helps the developers of deceptive apps, such as scam cryptocurrency wallets.

Issues like these are difficult. Human ingenuity can and always will find ways around any form of automatic scanning and checking. Potentially, there are simple answers, but these have prohibitive costs. For instance, repositories could in principle insist on manual inspection and approval of every version of every app – but that would either impose a large financial cost, to pay all those inspectors for their work, or if it were community-driven, open the system up to exploitation. Unpaid volunteer quality checkers could be bribed to approve malicious apps, for instance.

Indirectly, the issues parallel those of social media websites. If all posts had to meet the same legal standards as professional publications – such as, say, The Register – then the problems of fake news and viral disinformation would be vastly diminished, at least. But then, so would the volume of posts, killing the services' appeal. All the free sites would have to become subscription-based to afford the services of professional editors.

Of course, some might argue that this would be no bad thing. By the same token, some would see it as desirable that Linux distros only include apps from their own relatively small, manually packaged, human-inspected repositories, and questionable external apps are strictly limited. That would merely open up the big distro vendors to even more competition from fringe community efforts than they already face, though. ®