https://pagure.io/workstation-ostree-config/c/a0788c51ee3c9e42aca6bc1c9fbf2f608ade6596
is the only thing bringing in bzr and subversion to the host. I think we should probably document using flatpak-builder from inside a dev (podman) container.
bzr
subversion
flatpak-builder
podman
Another thing we could do in addition is to downgrade those deps to Recommends?
Recommends
/cc @mclasen
Given that we do have buildah on the host, i don't see why flatpak-builder shouldn't be there as well.
Recommends seems like an ok solution to me.
This is a tricky topic. In the default Dockerfile model, there is basically no usage of the host, and that's supported by buildah bud. Now, it's definitely true that buildah was oriented around the idea of reusing the host tooling. However, this has created a powerful tension with reproducibility.
Dockerfile
buildah bud
buildah
(It's also possible to use buildah from a container itself, though there are some tricks to that)
We have bigger issues to fix for the near future for sure - I just want to have this issue to point people to when they ask "why is bzr on the host?".
flatpak-builder is not using host tooling, though. It uses tooling from the sdk, at least for the toolchain. source control, it takes from the host, evidently.
Shouldn't we encourage flatpak development through GNOME Builder instead?
Also a note that podman build now exists, so we don't strictly need buildah either in the host anymore. (Though I'm not entirely sure if there are addtional use cases that buildah provides that we want to support OOTB).
podman build
There's also an alternative approach to consider here: does flatpak-builder need to exist on the host at all? There's org.flatpak.Builder where the dependencies are isolated to within Flatpak. Looks like also org.gnome.Builder exists but it's still using flatpak-builder 0.10.x which is reasonably old. There's some bugs that might prevent this approach for now https://github.com/flathub/org.flatpak.Builder/issues
I'm closing this issue - if the problem persists, please open a bug report in https://github.com/fedora-silverblue/issue-tracker/issues.
Metadata Update from @tpopela: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.