Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Bastien Nocera <hadess hadess net>]

On Fri, 2017-11-03 at 19:03 -0500, mcatanzaro gnome org wrote:
> Hi,
>
> Currently about half of the GNOME core apps are unremovable in GNOME 
> Software. It's the set of apps that are not new additions to core
> over 
> the past two years, but at this point that's entirely arbitrary. So
> we 
> need to find a better criterion for determining what should and
> should 
> not be unremovable.
>
> In the interests of allowing users to replace core apps with their 
> preferred alternatives, I'd like to propose that only the most 
> essential applications -- stuff that cannot plausibly be packaged as
> a 
> properly-sandboxed flatpak -- should remain unremovable. 

I can only say that I have problems understanding what the problem is,
and how this is a reasonable solution.

A number of applications currently set as mandatory are needed to have
a reasonable experience as designed. This is what we test, and what we
would want users to experience. Breakage caused by a particular
application being removed when it's "mandatory" should go as far down
the list of bugs to fix as it could probably go.

> Specifically, 
> I propose that <mandatory_for_desktop>GNOME</mandatory_for_desktop>
> be 
> removed from the appstream metainfo for all of our apps

Which doesn't require the user to have a replacement installed. Which
causes different, possibly broken, experiences to what is designed.

>  except the 
> following four:
>
>  * gnome-screenshot
>  * gnome-software
>  * nautilus
>  * yelp

I see no reason why those can't be sandboxed. They can be sandboxed
just about as well as most of the other apps can be, eg. with tons of
holes poked in the sandbox. Calendar needs access to the calendar data
shared with Evolution and gnome-shell, all the finding & reminding
applications need access to the per-user Tracker database, Videos needs
unhindered access to gvfs and raw disc devices, etc.

> This matches one of Javier's proposed moduleset changes [1].
>
> Thoughts?

See my answer to Allan later in the thread, I don't think this is the
right solution.

Cheers