com.valvesoftware.Steam.CompatibilityTool.Proton-GE VS flatpak-external-data-checker

I just noticed that even tho I installed Proton GE from Flathub using flatpak install com.valvesoftware.Steam.CompatibilityTool.Proton-GE -y and the repo seems to be updated to the latest version of Proton GE, the version on my system that steam lets me choose is version 7-36.

According to Github issue/PR #126 new builds are failing because of a bug in flatpak-external-data-checker or some incompatibility between the two projects at least.

Are you using the Proton-GE flatpak? I reported this bug here a few days ago: https://github.com/flathub/com.valvesoftware.Steam.CompatibilityTool.Proton-GE/issues/79 Unfortunately the build with the fix failed so no update was published. I ended up uninstalling that flatpak and moved to ProtonUp-Qt to manage my Proton versions

You can also get Proton-GE as Flatpak. I'm using the beta branch & enabled flathub-beta repo for that reason: https://github.com/flathub/com.valvesoftware.Steam.CompatibilityTool.Proton-GE/tree/beta

For Steam, from my testing, the Flatpak version (a way to get the same version of apps on any distro) should work just fine now (Protontricks and Proton-GE are also available on Flatpak). But you should really only install Flatpak version only if you have trouble with normal Steam.

Proton 5.13 introduced sandboxing using Valve's pressure-vessel that wouldn't stack with Flatpak. Users had to install one of the Proton community builds from Flathub (Proton, Proton-Experimental, Proton-GE) or stick with older upstream releases.

> Maybe. The CI rules should be made public in that case, though, surely? Maybe they are?

Agreed, but thankfully they are. The PRs link to <https://github.com/flathub/flatpak-external-data-checker>. That said, it'd be clearer if the flathubbot 'user' profile also linked to that URL.

> The enormous amount of value the distros bring [...] is audit of packages (and packaging).

Yes, auditing against supply chain attacks is good! But there's also a risk in running outdated software. I don't have easy answers. But if automation leaves more time for the hard part, great.

Flathub provides an excellent tool to keep your dependencies up to date, so it's just a matter of adding it to the manifests. Besides, who says 'dependencies not being updated enough' is a valid metric to determine the quality of a package? LOL.

According to Github issue/PR #126 new builds are failing because of a bug in flatpak-external-data-checker or some incompatibility between the two projects at least.

I'm surprised the documentation says that since Flathub itself runs its CLI scripts via Flatpak: https://github.com/flathub/flatpak-external-data-checker

Another thing you could add would be to tag your releases on GitHub, add a tag field next to the commit one, and add an x-checker-data section to the manifest so the Flathub bot will automatically open PRs to update the Flatpak release when you update your repository.

See f-e-d-c, and if you're not planing to submit to Flathub, then look at the GitHub workflow example there. Be aware that auto-merging is not acceptable for anything other than extra-data sources.

Unfortunately the maintainership of the Zoom Flatpak on Flathub has been a bit slow, but you can still install it since the Flathub bot do automatic builds whenever there's an update, thanks to the provided flatpak-external-data-checker service.

There is https://github.com/flathub/flatpak-external-data-checker which automatizes the update pull requests including dependencies. Flatpak has other downsides, but security or not getting the latest and greatest is not one of them.