Repository navigation
RFC: parameterize Flatpak SDK versions via manifest template #4887
Description
Context
PR #4888 pins org.freedesktop.Sdk.* extensions to an explicit branch
(25.08) because they were previously falling back to the GNOME SDK's
runtime-version (50). See the fix for details.
Proposal
To avoid hardcoding SDK branches in multiple places (and to keep the
GNOME / freedesktop versioning schemes independent), I'd like to
introduce a template + generator:
com.usebottles.bottles.Devel.json.templatewith@GNOME_VER@and
@FREEDESKTOP_VER@placeholders.build-aux/gen-manifest-flatpak.shthat renders the final.json
viasedfrom two variables at the top of the script.- The generated
.jsongets.gitignored.
I have a working prototype in a branch and can submit a PR.
Open question — FEDC
The update-manifest.yml workflow runs flatpak-external-data-checker
against build-aux/com.usebottles.bottles.Devel.json. If the manifest
becomes generated, FEDC would need to operate on the .json.template
instead. Would that work, or is there a reason to keep the checked-in
manifest as-is?
Looking for feedback before submitting a PR.
Activity
[-][Bug]: unhardcode Flatpak SDK versions in manifest[/-][+]RFC: parameterize Flatpak SDK versions via manifest template[/+]hopsayer commentedon Oct 28, 2026
Closing as not planned. The premise of this RFC turned out to be wrong: when building with --install-deps-from=flathub, flatpak-builder resolves the sdk-extensions branch from the GNOME SDK metadata (25.08 for GNOME 50), it does not fall back to runtime-version. I could not reproduce the original error on a clean setup; the confusion came from org.flatpak.Builder pulling its own 26.08 extensions next to the 25.08 ones. So the explicit pin in #4888 was unnecessary (and the id/arch/branch form is not valid there anyway), and a template + generator would only complicate things: it would require reworking update-manifest.yml/FEDC and the CI workflows, for a small gain since the remaining 25.08 literals change roughly once a year. Thanks to @mirkobrombin for the review. If keeping the versions in sync becomes a real maintenance problem, a lightweight CI check comparing them against the SDK metadata would be a better fit and can be proposed separately.
github-actions commentedon Oct 28, 2026
Invalid issue, please follow the template.
https://github.com/bottlesdevs/Bottles/issues/new/choose