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

[Bastien Nocera <hadess hadess net>]

On Tue, 2017-11-07 at 11:05 +0000, Allan Day wrote:
> Bastien Nocera <hadess hadess net> wrote:
> ...
> > I don't think that applications such as Calendar, Contacts, or
> > finding
> > and reminding apps should be removed from the requirements for a
> > well-
> > rounded, default desktop. How they're installed is a technical
> > question
> > that's not relevant to the fact that they're needed.
>
> That's certainly true. I'm mostly coming it this from a direction of
> a) trying to figure out what the user experience will look like on a
> flatpak-based system and b) having done some digging, feeling
> somewhat dissatisfied with the current use of
> <mandatory_for_desktop>. Particular issues that I see:
>
> 1. <mandatory_for_desktop> is only respected by Software or other
> "app centers", so you get different behaviour with the command line,
> which lets you install and remove apps that Software doesn't. This
> adds complexity, makes testing difficult, and introduces bugs. It
> also creates ambiguity; I don't think anyone is really sure what the
> experience is supposed to be.

I think that's actually a benefit. rpm/dpkg don't know about Flatpak,
and vice-versa. But Software knows both, and I should be able to remove
the distro provided version of the software if I've installed the same
"mandatory" app using Flatpak (they should have the same ID, otherwise
it's a bug).

Installing Flatpaks and removing RPMs is how some of us are slowly
edging towards Flatpak, dog-fooding Flatpak itself, the infrastructure
around it such as portals, and the software itself if we use nightlies.

> 2. In Software, <mandatory_for_desktop> is used to hide apps that
> belong to other desktops. In part I think this is motivated by the
> desire not to end up with identical apps (because stock apps tend to
> use the icon theme and often have identical names). However, it has
> the side-effect that applications that could easily be installed
> can't be. This is because it equates something being essential to an
> environment as meaning that it shouldn't be available outside of it,
> which I don't think is always the case - we might well say that
> Photos is essential to GNOME 3, but that doesn't necessarily mean
> that it shouldn't be installable on a non-GNOME system.

That seems like a problem in the appstream format which needs to be
fixed, and possibly have better replacements. Incidentally, do you
rename Photos to GNOME Photos when the current desktop isn't GNOME?

> 3. I guess I just find it strange that this mechanism is so
> decentralised. Can anyone use <mandatory_for_desktop>? Who makes the
> decisions about what's included and what isn't? How is that monitored
> and managed?

If the lack of centralisation is a problem, we can move that "you can't
uninstall this" list to gnome-desktop for the GNOME desktop. It would
make it easier for the release team to maintain, and curate.

> Relying an the ostree/flatpak split to determine which apps are
> removable has some advantages in relation to this - it would remove a
> layer of configuration, you'd get a consistent experience and GUI
> tools would be transparent in how they operate, it would be the OS
> builder who decides what forms part of the product, and projects
> could decide what to make available as standalone apps simply by
> making them available as flatpaks or not.
>
> Maybe there are issues with this approach - and I certainly take the
> point about updates - but maybe it's also illustrative of what we
> ought to be aiming for.

I don't think that the underlying technology should be used as the
safeguard for whether or not something can be uninstalled.

As a case in point, most core applications on iOS, the mail client for
example, are shipped and updated with the OS (the "ostree" in your
example above), but can be "removed" (hidden actually). The mail client
is core, can't be removed physically, but can be removed from view.

So the OS technology is always going to allow us to remove/hide. How to
add back is probably relevant.

I think the short answer to this thread is that we need use something
other than mandatory_for_desktop.