Flathub JSON recipes

[Jorge García]

Hi,

I think the actual workflow based on pull requests was decided as a v1 at
the GTK Hackfest in March [1], but the original goal was to have some sort
of web dashboard were developers could add their apps and configure remote
git repositories and branches where to find build recipes.

There are some nice mockups by Allan [2] and me [3] (not so nice)
presenting this idea and other concepts like having different publishing
channels like in Google Play and the Ubuntu Store.

Best regards,
Jorge

[1] https://github.com/flathub/flathub/wiki
[2]
https://github.com/flatpak-design-team/flathub-mockups/blob/master/png/add-app.png
[3] https://drive.google.com/open?id=0B-021DnJVTcZYTVCbHlyb3Z3eGs

On Sat, Aug 5, 2017 at 12:59 AM, Aleix Pol <aleixpol at kde.org> wrote:

> 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
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20170805/291b8a7c/attachment.html>