Re: All stable flatpak builds moved to flathub

[Alexandre Franke <afranke gnome org>]

Let me start by making it clear that I am a huge fan and advocate of
Flatpak and that I am mostly expressing concerns here.

Please keep in mind while reading this thread that this is not only a
technical matter, but also one of policies and guidelines.


On Mon, Nov 13, 2017 at 1:21 PM, Alexander Larsson <alexl redhat com> wrote:
> Flatpak itself is completely decentralized, in that anyone can (and do)
> create repos that anyone can install from. All these are on equal level
> in the CLI and in terms of features, and none are installed by default.

Right, we all agree on that.


> However, this leads to a pretty crappy user experience both for users
> who have to hunt for trustworthy repos all over the net, and for
> developers who each have to play sysadmin and maintain the
> infrastructure for a repo.

So basically we’re not using what makes the strength of flatpak
because it’s hard?

I do understand that some small projects with limited workforce will
need to rely on third parties and in that I see value in what Flathub
is right now, but:
* I don’t think there should be a single “Flathub” (as a repo hosting
platform), but that Flathub itself should indeed be the way to
discover the platforms[0].
* I don’t think GNOME apps should have been moved away from GNOME
infrastructure[1]. Yes, anyone can host their own repository, but if
even GNOME didn’t bother why would anyone else?


> So, the middle-road we've chosen for flatpak is to have one repo that
> has some level of review/testing that has most apps, so that people can
> get started easily.

Flatpak is seen and advertised by many as a way to shift the balance
from distributions to upstream developers. By going back to a single
repository, you’re cancelling that effect to some extent. Upstream
developers used to depend on distribution packagers to be shipped, now
they are depending on Flathub people to either review a PR or packing
it flat themselves.

Instead of a central repository, Flathub could have been a search
engine, or directory, or DHT, or… any similar mechanism that would
solve the problems you highlight without losing its potential.


> I'm not sure what you mean by "federation",

Hopefully I’ve cleared up what I meant now.


> but we don't plan to ever
> have one locally defined remote name resolve to a multitude of
> independent app sources. We are however working on distributing that
> repo, so that you can have e.g. a local, partial mirror, even ones
> discovered via avahi. However, each remote name is tied to one GPG key,
> so the source of the original builds are always one entity.

“Each remote name” doesn’t mean much when everyone hosts their
applications on the same remote and there is little incentive to do
otherwise.


On Mon, Nov 13, 2017 at 1:24 PM, Simon McVittie <smcv collabora com> wrote:
> The flatpak tool and library already support just as much federation as
> e.g. apt, git or jhbuild- you can add as many remotes as you want.

That is not federation though, but I grant you it’s decentralization.


> Apps and their runtimes don't even have to come from the same place:
> for example, an app that is not hosted on Flathub itself can use the
> freedesktop and GNOME runtimes from Flathub.

Yes, and that part is great.


> If there is something else that you think flatpak should do to support
> federation, I'd suggest opening a feature request.

Sure, but I don’t believe a vague and unspecific feature request would
get us anywhere, which is why I asked first if there was anything
planned on this topic. I also don’t know what form that would take,
although I risked some suggestions above, and I don’t have the deep
technical knowledge of the flatpak architecture that you and others
here have, so I would be hard pressed to tell you what you need to
implement.


> That doesn't mean that some level of centralization isn't helpful from a
> UX point of view.

Sure.


> Analogously, GNOME uses decentralized tools (git,
> jhbuild and a web browser), but requires official GNOME modules to
> be hosted on git.gnome.org,

which is mirrored at least on Github

> track their bugs on Bugzilla

and I wish there was a way to work with those in a decentralised
manner (but the sad state of decentralised bugtrackers is off-topic
but in a nutshell “why can I `git commit` on a train but not
read/comment on a bug report?”) (that concern is also valid for Gitlab
if/when we switch to it)

> and release via download.gnome.org;

which, I believe, has mirrors? To be honest, like most people, I don’t
get my GNOME software from there so I don’t really think about that as
a problem.


> apt can install packages from anywhere, but Debian
> doesn't really support installations where packages didn't all come
> from the Debian archive, and Ubuntu doesn't really support installations
> where packages didn't all come from the Ubuntu archive; and so on.

Right. And that’s a bit of a tangent. GNOME could say they don’t
support Flatpaks that don’t come from the GNOME infrastructure.

Also, the parallels you draw to GNOME, Ubuntu and Debian are a bit
irrelevant because in those cases we’re talking about a single entity
using an infrastructure for themselves, when the issue I’m raising is
*everyone* flocking to a common infrastructure.

Cheers,


[0] Flathub could still be one of the many hosting platforms, I just
wish it addressed the problem of finding the other ones.
[1] As a side note, moving GNOME apps to Flathub also means that now
GNOME developers either have to interact with Github (several
expressed reluctance to do so for various reasons) or wait/hope for
someone else to do it for them, once again missing an opportunity.

-- 
Alexandre Franke
GNOME Hacker & Foundation Director