Out-of-Process Flatpak
Status: In Progress
Branch: wip/chergert/gnome-builder-flatpak
Problem
We've experienced a number of crashes inside of libflatpak due to how we need to use it from within Builder. It would be a huge benefit if we could move that code out of process into a gnome-builder-flatpak worker process so that crashes do not take Builder down with it. Additionally, we could test the implementation better since it would not require a complex Builder setup to do so.
It would also be nice if we could rely on DBus signals so that we get updates about new/existing runtimes and apps.
Goals
Keep memory usage with regards to flatpak contained in gnome-builder-flatpak
- Be resilient from crashes in libflatpak
- Improved testing of flatpak components
Anti-Goals
Affected Modules
This should be contained to the flatpak plugin as it can be an implementation detail.
- Flatpak plugin (src/plugins/flatpak)
Interfaces
No new interfaces are required.
Risks
The flatpak related code can be brittle in terms of keeping everything up to date with changes in Flatpak. Moving this to an external process shields the UI process from this, but we still need to be sure to keep the flatpak worker process modern and flexibile with regards to what flatpak versions we support.
Some APIs are intended to be fast, such as checking if a runtime contains a certain binary. We may want to keep that implementation in process (and simply use the deploy-dir/staging-dir to manually check for binaries).
Implementation Details
- Use DBus over STDIN/STDOUT like gnome-builder-git.
- Process is spawned within Builder's mount/pid namespace.
- Avoid using libide code if we can, to avoid bringing in too much code from Builder UI process.