2017-10-04 12:45 GMT+02:00 Simon McVittie <s...@debian.org>:
> Control: reassign 877684 gnome-software
> Control: block 877684 by 876862
>
> On Wed, 04 Oct 2017 at 10:22:19 -0000, David Seaward wrote:
>> Source code (for plugin):
>> https://git.gnome.org/browse/gnome-software/tree/plugins/snap
>
> This is part of the gnome-software package upstream, so this is a feature
> request for Debian's existing gnome-software source package (adding a
> new binary package to it) rather than a request for an entirely new
> source package to be packaged. Reassigning accordingly.
>
> The GNOME maintainers are unlikely to want to enable this while snapd
> is in danger of being autoremoved from testing, so I'm setting this
> as blocked by #876862.
>
> I'm also not sure that this would be such a good idea to enable while
> snap relies on Ubuntu-specific AppArmor features for sandboxing: without
> AppArmor, it lacks a security boundary, as far as I'm aware. Those kernel
> patches seem to be finally going upstream, so perhaps that objection
> can go away soon.
>
> The GNOME maintainers would probably also want someone who regularly
> uses snap (perhaps someone from Ubuntu/Canonical?) to commit to doing
> any necessary testing and debugging for this plugin on Debian.
Adding to this, I actually had this enabled in gnome-software until
the feature started to require snapd-glib, so if we want it back we
need the snapd-glib package packaged and snapd properly integrated
with Debian. AFAIK both things are work-in-progress at the moment.
The snapd plugin just like the other bundling plugins was/is a
separate package, so problems with it would be less severe (because at
the moment users need to make a conscious decision to enable a
bundling plugin, as opposed to having it by default).
Cheers,
Matthias
