[Dev] GNOME Software, archlinux-appstream-data, and Flatpak

[bill-auger]

On Thu, 2018-05-31 at 16:50 -0300, Freemor wrote:
> Would supporting flatpak install count as recommending non-free software? Like
> linking to addons.mozilla.org does.
> 
> Is it even possible to create a "your-freedom" style flatpack?

brainblasted pointed out that most package managers including pacman may be
configured to use arbitrary source repos - that is true but if the user re-
configures the software from the default state, it is of no concern to the FSDG;
so that is not the issue - but if in it's default state, the program will
actively list and assist installing non-free programs then that would be an FSDG
problem

in pacman's default state, the 'your-freedom' packages prevents known non-free
packages - this is possible becasue the default repo package set is well-curated 
and known, and fairly stable - for most of the third-party repos i have seen,
the task of maintaining a comprehensive blacklist would be intractable to
impossible - flathub is not one that i looked at; but most of them are not at
all curated and more like the AUR, allowing literally *anyone* to publish
packages


On Thu, 2018-05-31 at 15:59 -0400, Christopher Davis wrote:
> there could be a completely free flatpak repo to use instead 
> of flathub. Purism is interested in getting one of these set up for 
> PureOS,
> and I've mentioned the idea of splitting Flathub's nonfree apps off 
> from the free apps
> so an FSDG-compliant distro could use Flathub

that is the most reasonable solution but would be a lot of work and afterwards,
someone still needs to host it and maintain it

On Thu, 2018-05-31 at 16:01 -0400, Christopher Davis wrote:
> Another option could be a flatpak-level patch that blocks nonfree 
> flatpaks from being installed, as flatpaks include license information 
> with them.

another fine option perhaps, and probably much less work to implement; but again
if like most of the repos ive seen, the licensing information is supplied by the
uploader, and the uploader can be *anyone*, and so is not verified by a trusted
curator, then it is not reliable information and renders the exercise pointless 

much like freemor, i consider third-party repos more troublesome than valuable
but there is also a philosophical case to be made against container-based
distribution (several actually) - the main argument given for these container
deals is that it helps the developer support multiple distros by distributing a
consistent pristine state mostly isolated from the system - that may be true but
that is really should not seen as necessary - it is really not the place of the
upstream to support *any* distro - regardless of any implementation decisions
the upstream makes, the proper relationship between a distro and an a third-
party upstream software is that: it is the job of the distro to support the
upstream software on their distro, or drop it if it's dependencies are
unsatisfiable or it is otherwise un-maintainable or brings little value to the
distro

there is nothing preventing any user from compiling anything they want;
including 'gnome software' itself ('flatpak' is already in the repos) - put into
context, there is no imperative for any distro to support *any* particular
third-party program; *much less an entire package manager* with the can of worms
that opens - so it's value-to-maintenance-effort ratio had better be positive to
be considered for inclusion - that is why my main question was "how much work is
this going to be to setup" because i consider its value to be on the low side if
not negative

i have expressed most if this before it hit the mailing list; so i will probably
abstain from adding anything further to see what others have to say

i think the only thing that should be ensured is that it is possible for an end
user to compile 'gnome software' themselves - is there anything strictly
preventing this? or is it just the case that the blacklist is preventing the
arch package from installing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20180601/a3a75636/attachment.sig>