Discussion about publishing OBS Studio on Flathub directly

[GeorgesStavracas]

Currently, OBS Studio has 2 Flatpak manifests: one hosted in Flathub, and the upstream one. I'm maintaining both of them, but this is not a sustainable situation. There are various benefits of prioritizing the upstream's manifest:

• OBS Studio's CI immediately catches build errors;
• It's managed by upstream;
• Releases can be automatically published based on tags;

I really would like to stop maintaining 2 different manifests for the same app. I already do that for 2 other apps, and it's frustrating and annoying. I'd like to publish OBS Studio releases on Flathub directly, using flat-manager and @bilelmoussaoui's GitHub action.

[ramcq]

Hi @GeorgesStavracas - this makes a lot of sense but currently we only have a handful of 3rd party direct publishing setups in place for runtimes and Mozilla Firefox as a special case. We'd like to maintain the rule that only the publisher of the application/runtime is allowed to upload directly rather than source builds, but it seems that in this case it would come directly from OBS Studio's own infrastructure/actions, which is good. The main problem is that I think we need a better way to automate/manage these kind of relationships as they are currently done manually. What we'd want is a way for issuing/updating the flat-manager tokens to be automated - so that we could have PRs sent to some documented configuration, rather than doing everything ad-hoc. I've not thought at all about how to do this "scaling up" but perhaps @barthalion or @alexlarsson have some ideas.

[TiZ-HugLife]

The upstream manifest for OBS Studio is missing features that the flathub one has. For example, the extension infrastructure for plugins. I worked hard on that and the plugin manifests that use it. However the flathub one does not have CEF while the upstream one does. If you're maintaining them both, why are they so different?

[GeorgesStavracas]

However the flathub one does not have CEF while the upstream one does

Flathub Beta's OBS Studio has. It'll be enabled with the v27 release.

If you're maintaining them both, why are they so different?

They're serving different purposes for now. Upstream is used to generate a Flatpak bundle through CI. Flathub's is for production and release. I want upstream's one to be both.

[TiZ-HugLife]

That all sounds good to me. My local fighting game community makes use of my laptop for playing games and recording, and I need both WebSocket and Input Overlay. As long as they don't suddenly stop working when we need them, I'm down with anything you want to do. I did have to write a patch for OBS Studio to look for plugins in the new location though; should we get this re-implemented properly and upstreamed?

[GeorgesStavracas]

I did have to write a patch for OBS Studio to look for plugins in the new location though; should we get this re-implemented properly and upstreamed?

Yup, I'd like this patch to be merged upstream, and Flathub to ship a pristine, unmodified OBS Studio.

I need both WebSocket and Input Overlay

My idea with this moving forward is to extensively document the current plugin scheme, create a template for plugin developers to copy and use, and make Flahub the main way to distribute OBS Studio plugins on Linux. A nice collateral effect is that Flathub's policy of one extension per repo is that plugin authors would have their own repository, and thus control over the distribution of their plugins. How does that sound to you?

[TiZ-HugLife]

Can you take charge in merging that patch since you have maintainership upstream?

That sounds fine to me, but the authors for both of the plugins on flathub didn't want anything to do with the flathub packages. One did not respond at all. The other simply declined politely. I'm currently maintaining both repositories. And I don't mind continuing to do that, because I do need both plugins for my use case.

The whole process is pretty involved and I imagine that is part of why they don't want to get involved with it. A template for the manifest and appdata certainly would help, but app submission is kinda clunky by its nature. You clone the flathub repo, then you check out a new branch of a specific branch, then you make commits to that branch and make sure that branch gets pushed up, then you file a pull request and answer a bunch of questions... it's A Lot™. since I've done two plugins now, I'd be happy to be a sort of liaison for that process. Do the hard parts and hand over the resulting repo to the plugin authors.

[Be-ing]

Hi, I'm a maintainer of Mixxx and Tenacity. I just updated the Mixxx manifest for the latest release. I'm also interested in setting up the same workflow for prerelease builds where a build is run for every commit to our development and beta branch and automatically published on Flathub. Duplicating the manifest in the application repository and Flathub's repository would be cumbersome.

[Be-ing]

@ramcq

What we'd want is a way for issuing/updating the flat-manager tokens to be automated

Are you sure you want that to be automated? I'd imagine that could be abused. If you could publish contact information for whoever has the authority to create flat-manager tokens for upstreams to use, that would be helpful.

[tibequadorian]

The publisher link on https://flathub.org/apps/details/com.obsproject.Studio still links to https://github.com/flathub/com.obsproject.Studio/graphs/contributors/ which is wrong.

[GeorgesStavracas]

Yes, that needs fixing

[barthalion]

This is somewhat addressed with flathub-infra/frontend#239 but I need to submit PRs to projects maintained outside Flathub and the beta website is still just a beta.