Re: All stable flatpak builds moved to flathub

[Tirifto]

Is it of no concern that the main repository through which GNOME is to
distribute all stable flatpaks (Flathub) contains several malicious,
non-libre programs? (With nothing reminiscent of radical separation
from the libre ones, too, from what I’ve noticed.)

Regards
// Tirifto

> The goal of flathub (https://flathub.org/) is to be a single location
> where you can find builds of the latest stable version of linux
> desktop applications, ideally maintained by the upstream author. That
> way the experience for flatpak users is much nicer, just add one
> remote and you can then find all apps via e.g. gnome-software.
> 
> In line with this, I last week moved all the remaining applications
> from the gnome-apps-nightly stable branch to flathub and disabled
> further builds from the stable branch. gnome-apps-nightly is still
> used for the semi-automatic nightly builds from git master though.
> 
> This means that in the future, stable releases that wants to be
> flatpaked should be built via flathub. I wrote some docs on how do to
> this on the flathub wiki:
> 
>   https://github.com/flathub/flathub/wiki/Maintaining-an-application-
> on-flathub
> 
> This week mail out all the maintainers of the current apps and ensure
> they have access to the new repos. If anyone wants to add new apps to
> flathub, the instructions for that are here:
> 
>   https://github.com/flathub/flathub/wiki/Submission-Guidelines

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: All stable flatpak builds moved to flathub

[Alexander Larsson]

On Tue, 2017-11-14 at 19:25 +0100, Tirifto wrote:
> Is it of no concern that the main repository through which GNOME is
> to
> distribute all stable flatpaks (Flathub) contains several malicious,
> non-libre programs? (With nothing reminiscent of radical separation
> from the libre ones, too, from what I’ve noticed.)

All apps are marked with the license in the appdata, and any
proprietary ones have LicenseRef-proprietary, which gnome-software
displays properly. You can even make gnome-software completely hide
them.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a leather-clad coffee-fuelled rock star from the Mississippi delta. 
She's a chain-smoking communist traffic cop prone to fits of savage, 
blood-crazed rage. They fight crime! 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: All stable flatpak builds moved to flathub

[Alejandro HC]

>
> 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?
>
>

This makes me think a little. Before I thought that flathub would be a site
that would allow me to find applications in flatpak format from anywhere,
for example if Steam had its own repo, I could find it anyway in flathub,
however, now I see that developers "must" host their applications in that
repository ... what sets it apart from the Canonical Snap store in practice?

I understand the advantages of having everything in one place as a
repository, but I thought that flathub would follow a more open model and
could discover third-party apps repos.

Those are my two cents as a user.

*Hugo*
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: All stable flatpak builds moved to flathub

[Alexandre Franke]

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  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  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 

Re: All stable flatpak builds moved to flathub

[Simon McVittie]

On Mon, 13 Nov 2017 at 12:11:04 +0100, Alexandre Franke wrote:
> On Mon, Nov 13, 2017 at 11:49 AM, Alexander Larsson  wrote:
> > The goal of flathub (https://flathub.org/) is to be a single location
> > where you can find builds of the latest stable version of linux desktop
> > applications, ideally maintained by the upstream author. That way the
> > experience for flatpak users is much nicer, just add one remote and you
> > can then find all apps via e.g. gnome-software.
> 
> Such centralisation means a single point of failure. By supporting the
> addition of remotes, flatpak seemed to have potential for
> decentralisation. Is some kind of federation or other way to address
> this issue on the roadmap?

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. 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.

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

That doesn't mean that some level of centralization isn't helpful from a
UX point of view. Analogously, GNOME uses decentralized tools (git,
jhbuild and a web browser), but requires official GNOME modules to
be hosted on git.gnome.org, track their bugs on Bugzilla and release via
download.gnome.org; 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.

smcv
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: All stable flatpak builds moved to flathub

[Alexander Larsson]

On Mon, 2017-11-13 at 12:11 +0100, Alexandre Franke wrote:
> On Mon, Nov 13, 2017 at 11:49 AM, Alexander Larsson  > wrote:
> > The goal of flathub (https://flathub.org/) is to be a single
> > location
> > where you can find builds of the latest stable version of linux
> > desktop
> > applications, ideally maintained by the upstream author. That way
> > the
> > experience for flatpak users is much nicer, just add one remote and
> > you
> > can then find all apps via e.g. gnome-software.
> 
> Such centralisation means a single point of failure. By supporting
> the
> addition of remotes, flatpak seemed to have potential for
> decentralisation. Is some kind of federation or other way to address
> this issue on the roadmap?

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.

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, 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.

I'm not sure what you mean by "federation", 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.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's an oversexed hunchbacked librarian possessed of the uncanny powers 
of an insect. She's an orphaned blonde queen of the dead in the wrong 
place at the wrong time. They fight crime! 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: All stable flatpak builds moved to flathub

[Alexandre Franke]

On Mon, Nov 13, 2017 at 11:49 AM, Alexander Larsson  wrote:
> The goal of flathub (https://flathub.org/) is to be a single location
> where you can find builds of the latest stable version of linux desktop
> applications, ideally maintained by the upstream author. That way the
> experience for flatpak users is much nicer, just add one remote and you
> can then find all apps via e.g. gnome-software.

Such centralisation means a single point of failure. By supporting the
addition of remotes, flatpak seemed to have potential for
decentralisation. Is some kind of federation or other way to address
this issue on the roadmap?

-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

All stable flatpak builds moved to flathub

[Alexander Larsson]

The goal of flathub (https://flathub.org/) is to be a single location
where you can find builds of the latest stable version of linux desktop
applications, ideally maintained by the upstream author. That way the
experience for flatpak users is much nicer, just add one remote and you
can then find all apps via e.g. gnome-software.

In line with this, I last week moved all the remaining applications
from the gnome-apps-nightly stable branch to flathub and disabled
further builds from the stable branch. gnome-apps-nightly is still used
for the semi-automatic nightly builds from git master though.

This means that in the future, stable releases that wants to be
flatpaked should be built via flathub. I wrote some docs on how do to
this on the flathub wiki:

  https://github.com/flathub/flathub/wiki/Maintaining-an-application-on-flathub

This week mail out all the maintainers of the current apps and ensure
they have access to the new repos. If anyone wants to add new apps to
flathub, the instructions for that are here:

  https://github.com/flathub/flathub/wiki/Submission-Guidelines

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a scarfaced gay waffle chef searching for his wife's true killer. 
She's a sharp-shooting winged femme fatale from a secret island of 
warrior women. They fight crime! 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list