Re: GNOME Shell and system extensions being part of a mode

[Jason DeRose <list derose io>]

On Wed, Oct 25, 2017, at 06:15 AM, Didier Roche wrote:

> My proposal would be:

> * Do not propose updating system extensions being part of a mode if his

> mode is the current one.

> * If a there is an installed system extension and a local user one, but

> this extension is part of the current mode, only load the system

> extension code. This prevents people going to another session, being

> prompted to update the extension and doing so knowingly or not, and be

> back in an unsupported use case. The session mode will only run code

> that it knows about.

> * This means reworking slightly the logic of the DBUS interface so that

> 3rd party apps (Tweaks) or browser extension, shows up the correct

> status (extensions enabled/disabled, separated by updatable status or

> not, separated from error status, system or local user extensions). This

> would mean potentially changing and break the DBUS API, apdating -prefs

> and LG (easy same repo), Tweaks and browser extensions. Would that be

> acceptable? I can as well work on making it backward compatible and

> exposing a V2 api on the bus.

The problem you describe is a real issue. The flip problem is also an issue, where the user intends to install a newer version. This is an issue in distros where many extensions are shipping out of the box, and the package manager competes with e.g.o. This is also an issue where the user installs a development version of an extension and the Update notifier thinks the e.g.o is newer and continually requests that the user update.

However, giving system extensions favor of a user's local extensions seems counter-intuitive and blocking the user from updating extensions on his own system seems potentially maddening.

How about namespacing the installation directories and having e.g.o only check directories from its own namespace?  And Tweak Tool could show each installed instance with the namespace and version?

Thanks!