Flathub JSON recipes

[Aleix Pol]

On Fri, Aug 4, 2017 at 4:11 PM, Robert McQueen <ramcq at gnome.org> wrote:
> Hi all,
>
> A commenter on my blog has just reminded me of something:
>  http://ramcq.net/2017/07/29/welcome-flathub/#comment-144379
>
> I was discussing this with Christian Hegert at GUADEC and we forgot to
> follow up any further during the Flatpak/Flathub BOF. Builder relies on
> having the .json file inside the project repository as a complete
> description of how to build and run it - dependencies, runtime, etc - so
> you can check out a project, build & run in two clicks of the mouse.
>
> For a while in GNOME, we were working on including the .json file within
> each module, which obviously works well with this flow, but now (seeing
> Alex push a lot of new, separate modules into Flathub for the GNOME
> apps) the Flathub approach of separating the recipes from the
> application in separate repos breaks this flow.
>
> The commenter on my blog was also concerned about the split of repos and
> potentially of access permissions in this scenario, recreating some of
> the regular Linux distro structure of packagers and developers being
> distinct groups of people. Flatpak is aiming to disintermediate here -
> does Flathub need to do better at this too?
>
> Should/could we also support (and indeed, encourage) a mode where
> Flathub can follow a stable branch on a upstream repo, and instead
> obtain the .json from there?
>
> I can see certain activities where Flathub would very much wish to have
> the source on hand to do things like CVE scanning or other kinds of
> linting, but these can also just as likely be done with mirrors or
> triggered as part of the build flow.
>
> Any thoughts?

I agree with your point of view.

We should make sure for this new approaches to distributing
applications that the application maintainers are responsible for the
recipes.
The place to do that is the project's repository.

This has other ramifications, for example:
- when you want to contribute, you have in the same place the recipe.
- you can track the dependency differences in the different project branches

There's some technology for that already, gnome is already using it
for some projects [1]. It's just not being used on Flathub AFAIK.

Furthermore, Flathub possibly could allow more than one version of
applications, I think it's interesting how snap does it there with
channels. Users might want to switch between lts, stable and nightly
easily.

Aleix

[1] https://github.com/GNOME/gnome-apps-nightly/blob/master/org.gnome.Nautilus.app