Packaging: the Homebrew cask workflow is dormant, and there is no Flathub package

[EtienneLescot]

Context

Most of the distribution plumbing already exists. State checked on 2026-08-10:

Channel	Workflow	Status
winget	publish-winget.yml	Configured. WINGET_IDENTIFIER=OpenScreen.OpenScreen is set; microsoft/winget-pkgs still only carries manifests/s/SiddharthVaddem/OpenScreen, so the new identifier lands on the next release.
AUR	aur-publish.yml	Configured (AUR_PACKAGE_NAME, AUR_SSH_PRIVATE_KEY).
Nix	bump-nix-package.yml	Configured.
Microsoft Store	—	MSSTORE_PRODUCT_ID set.
Homebrew cask	update-homebrew-cask.yml	Dormant — see below. (Update 2026-08-11: fixed and publishing; the tap carries 1.9.2.)
Flathub	—	Absent. (Update 2026-08-11: bigger than it looks — see the status note at the bottom.)

Two gaps remain.

1. The Homebrew cask job is skipped on every release

update-homebrew-cask.yml is gated on:

if: ... && vars.HOMEBREW_TAP_OWNER != '' && vars.HOMEBREW_TAP_REPO != ''

Neither variable exists on the repo, so the job is skipped every time — and a skipped job is green. This is the exact failure mode that publish-winget.yml documents in the comment above its own if:, after eight releases "succeeded" without publishing anything (#148). The same guard shape is still in place here.

• Create the tap repo (getopenscreen/homebrew-openscreen)
• Set HOMEBREW_TAP_OWNER and HOMEBREW_TAP_REPO
• Move the config check out of if: into a step that reports its absence, mirroring what publish-winget.yml now does
• Set the HOMEBREW_TAP_TOKEN secret
• Publish a cask — Casks/openscreen.rb at 1.9.2 landed in the tap on 2026-08-11
• Verify brew install --cask getopenscreen/openscreen/openscreen on a Mac

If the tap isn't wanted, delete the workflow instead — dormant-and-green is the worst of the three options.

2. No Flathub package

A Flathub search for "openscreen" returns zero results. It is the main Linux discovery surface (GNOME Software and KDE Discover both pull from it) and the only channel here with no automation at all. The AppImage/deb/rpm/pacman targets don't help — Flathub needs its own manifest submitted to flathub/flathub.

• Submit a manifest to flathub/flathub
• Wire release automation once the app ID is accepted

Deliberately not proposed

Chocolatey and Scoop. Windows is already covered by winget plus the Store; add them only if someone asks.

Why this is worth finishing

Beyond installation convenience, these are the highest-authority pages that link the project by name, and they intercept "install openscreen" before it reaches the stale third-party download mirrors currently outranking getopenscreen.com.

Status, 2026-08-11

Homebrew publishes. The chain is closed: the tap repository exists, HOMEBREW_TAP_OWNER and HOMEBREW_TAP_REPO are set, #340 moved the configuration test into a reporting step, and HOMEBREW_TAP_TOKEN was created as a fine-grained PAT with contents write on the tap alone. GITHUB_TOKEN could never have stood in for it — it is scoped to this repository and cannot push to a second one.

Proven rather than assumed: update-homebrew-cask.yml was dispatched at v1.9.2 (run 31535851764), every step green through Commit and push to tap, and Casks/openscreen.rb now carries version 1.9.2 with both architecture digests. For contrast, the previous run of the same workflow — the release event earlier the same day, before #340 merged — concluded skipped, which is the failure this issue was opened about, on the record one last time.

What is still unverified is the consumer end: brew install --cask getopenscreen/openscreen/openscreen needs a Mac, and neither the tap contents nor CI can answer for it. The DMGs it points at are notarized, since the Apple credentials are present, so it should not need the quarantine dance.

Flathub is a port, not a manifest. Flathub's requirements forbid the shortcut every other channel here uses:

All source available submissions must be built entirely from source code. This requirement applies to the main application component defined in the manifest, as well as any runtime dependencies included in the manifest.

Prepackaged binaries — .deb, AppImage or similar — are prohibited, and extra-data is not an escape hatch: it exists for non-redistributable sources, and upstream authorship implies redistribution rights, so a submission from this repository has no grounds to use it. OpenScreen is MIT, therefore source-available, therefore it must build inside the sandbox with no network. Concretely that means offline npm sources generated from the lockfile, vendored crates for the Rust compositor and the pipewire-capture helper, Electron from org.electronjs.Electron2.BaseApp — and ffmpeg built from source, which is the expensive part.

ffmpeg deserves its own paragraph, because it is what makes this a port rather than a manifest. scripts/fetch-ffmpeg.mjs pins a BtbN prebuilt shared tree, which the rule above rejects. Substituting the org.freedesktop.Platform.ffmpeg-full extension does not work either, and the reason is specific: scripts/build-linux-compositor-addon.mjs renames every ffmpeg dynamic symbol in the libraries the addon ships, because Electron links Chromium's own stripped libffmpeg.so into the same address space and the addon would otherwise bind to that. Doing so needs headers and libraries the build owns; the extension ships libraries without dev headers. So ffmpeg has to be compiled inside the manifest, and whether that reproduces the tree the addon was actually tested against is the open question. None of it can be built or verified on a Windows machine — flatpak-builder is Linux-only — which is what #347 exists to settle in CI.

One defect found in the metadata that just landed. build/com.getopenscreen.OpenScreen.metainfo.xml declares <launchable type="desktop-id">openscreen.desktop</launchable>, but Flatpak only exports desktop files prefixed with the app ID, so the Flatpak will ship com.getopenscreen.OpenScreen.desktop and this launchable will not resolve. The CI gate added in #340 cannot catch it: appstreamcli validate checks AppStream correctness, not Flathub's naming rules, which live in flatpak-builder-lint.

To be explicit about a non-problem, since it looks like one: electron-builder.json5 sets appId: com.etiennelescot.openscreen while the AppStream ID is com.getopenscreen.OpenScreen. These live in different namespaces and Flathub constrains only its own — the metainfo <id> must equal the Flatpak ID, which is the manifest filename, and those two already agree. The Electron appId does not need to change, and should not: macOS keys TCC grants to it, the cask's zap trash paths are built from it, and the Store identity is separate again.