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

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
and reminding apps should be removed from the requirements for a
rounded, default desktop. How they're installed is a technical
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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]