Michael Catanzaro commented:
Another option I'm starting to consider is to only build them as flatpaks (and preinstall them as flatpaks in our upcoming OS images). This seems the logical next step to me in the context of GNOME/gnome-build-meta#142
Surely that should be the goal. We don't have any reason to continue non-flatpak builds, right?
Its kinda weird, cause what we will end up publishing will be different from the manifest in the apps repo which is what Builder and the maintainers are going to be using to be using to build and test their apps. If everybody was using buildstream this wouldn't be much of an issue, but our current developer tooling is mostly around
flatpak-builderand bst adoption hasn't been great. I think we should aim for making it as painless as possible for the app maintainers, even if that means the RT would have to maintain a separate build definition (gnome-build-meta) and let the apps continue using their flatpak manifests as their source of truth.
Hm, this is a really good point. I took it for granted that the buildstream manifest would be the source of truth and that core apps would drop their flatpak-builder manifests. We really do not want to have two separate build definitions. It's an unmaintainable disaster; the whole point of gnome-build-meta is to unify all our core build definitions in one place.
But that doesn't work for users building the app locally in Builder. I think that's the only use-case that's not satisfied by buildstream. So we'll certainly need to discuss this.
+1, it seems redundant currently to doing it both ways. One issue though, is what would happen to the development/test experience with buildstream (nobody uses it yet, but we shouldn't make the workflow worse). Would this mean that for every change we would have to checkout a flatpak bundle and run that? And if so what would be the required changes in the bst plugin to make this as easier, like
flatpak-builder --installor such.
Good question.