Flatpak build
Opened this issue · 8 comments
I have been experimenting with the idea of providing a Flatpak for Higan and supporting apps (Icarus, and maybe Byuu?). The goal is to have the user be one flatpak install org.byuu.higan away from installing the app without having to care about the necessary runtime. The latter is still based on GTK2 for the official binaries, which is going away in most distros.
Right now, I am focusing on version 110 and managed to get a working build based on freedesktop runtime version 20.08 and GTK3, with a minimal amount of patching involved (path management mostly, see #133 and #134).
For Linux users interested in helping maintain the Flatpak build, please reach out.
I also have a working Flatpak for bsnes also built with GTK3 from current.
Not sure why the bsnes menu is back instead of grey as in higan 🤔
I filed bsnes-emu/bsnes#108 about the bsnes menu-bar thing.
I don't know much about Flatpak, but I'm cautiously interested — the idea of being able to ship bsnes with GTK+2 UI even when distros no longer support it seems pretty useful. However, I have questions:
- how difficult is it to build releases? Can we do it in our existing GitHub Actions CI system? Can we automatically push them to the central FlatPak repository, wherever that is?
- how difficult is is it to build nightlies? Can we upload them to a "preview channel" or something so people can test upcoming releases without having to build from source?
- How difficult will it be to build bsnes as a GTK2 app when GTK2 is no longer supported on any distro? Can we say "always build with platform version X.Y.Z" regardless of the underlying platform?
- Who pays for the central FlatPak repository, and how do they make money?
- What are the security implications of publishing as a FlatPak? Would we lose access to (say) raw /dev/input devices, or OpenGL shaders, or direct ALSA audio? Would we lose access to non-native file dialogs? Would we lose the ability to write out a save file next to the ROM file?
I don't know much about Flatpak, but I'm cautiously interested
Among the list of Flatpak features, I think those 3 stand out for higan / bsnes:
-
Stable platforms: runtimes provide the build toolchain and common libs. The freedesktop runtime is enough for us and is typically upgraded once a year.
-
Full control over dependencies: on top of the chosen runtime, you build the custom runtime necessary to build and run your app.
-
Distribution made easy: pretty much everyone using Flatpak has got Flathub installed. So publishing your updates to Flathub is enough to reach most Flatpak users.
the idea of being able to ship bsnes with GTK+2 UI even when distros no longer support it seems pretty useful
Well, freedesktop runtime got rid of GTK2, hence why I focused on GTK3 builds. It is possible to build GTK2 from the freedesktop runtime, but the fact that even conservative distros like Debian want to get rid of it (see this bug report) should signal that it's time to move on.
how difficult is it to build releases? Can we do it in our existing GitHub Actions CI system? Can we automatically push them to the central FlatPak repository, wherever that is?
Once a working Flatpak manifest is submitted, subsequent updates are just a matter of updating the release tag and the release information in the appstream metadata file. You can have a look at the Flatpak for OpenTTD for an example.
Flathub (the main Flatpak repo) has its own CI setup, with builders for all supported architectures and test repositories for PRs. New Flatpak releases are pushed twice a day, if I remember correctly.
how difficult is is it to build nightlies? Can we upload them to a "preview channel" or something so people can test upcoming releases without having to build from source?
I have never done nightlies personally, but can ask the Flatpak community for best practices. There is support for different "channels" if you want to submit preview releases in addition to stable releases.
How difficult will it be to build bsnes as a GTK2 app when GTK2 is no longer supported on any distro? Can we say "always build with platform version X.Y.Z" regardless of the underlying platform?
GTK2 is dead, like really dead. Yes, it would be possible to provide GTK2 with a freedesktop runtime. Using a more modern and supported toolkit (Qt5, GTK3, SDL2) remains more desirable.
Who pays for the central FlatPak repository, and how do they make money?
See the list of sponsors in the about page.
What are the security implications of publishing as a FlatPak?
What do you mean?
Would we lose access to (say) raw /dev/input devices, or OpenGL shaders, or direct ALSA audio?
Flatpaks are sandboxed by default and you add the necessary permissions to access features from the host. As of today, I have enabled input devices, hardware acceleration, pulseaudio, x11 and selected filesystem access (~/Emulation).
Would we lose access to non-native file dialogs?
No, you won't. But using portals is recommended for better integration.
Would we lose the ability to write out a save file next to the ROM file?
No, provided the relevant file system is exposed. We usually want to avoid exposing the full host or home file systems in favour of XDG directories (like xdg-documents) or targeted directories (like ~/Emulation).
GTK2 is dead, like really dead. Yes, it would be possible to provide GTK2 with a freedesktop runtime. Using a more modern and supported toolkit (Qt5, GTK3, SDL2) remains more desirable.
It will if someone fixes up hiro to work as well with GTK3 and Qt5 as it does with GTK2. I don't think we're there yet.
It will if someone fixes up hiro to work as well with GTK3 and Qt5 as it does with GTK2. I don't think we're there yet.
How do you measure that?
You can use flatpak-github-actions for CI but it can't publish to a remote yet and won't in the near future. Although setting it up is pretty simple and uploads a nightly bundle to github artifact for each pr/commit