GNOME Shell and system extensions being part of a mode

I want to propose some thoughts and potential rework around system extensions which are part of a mode towards update & QA process. In ubuntu, we implement an "ubuntu" GNOME Shell mode which enables some extensions by default ("ubuntu-dock" and "ubuntu-appindicator"). Those are respectively an ID rename of dash to dock (with different defaults for that one) and KStatusNotifier extensions, installed as system extensions in /usr/share/gnome-shell/extensions.

Why did we do that?

Once we release an ubuntu version, anything part of the distributions receives bug fixes only, but no behavior or new defaults are allowed for UI and behavior stability are permitted (apart from browsers, having exception). Consequentely, if our extension kept the same GNOME Shell extension ID than Dash to Dock, it would mean that any users can upgrade it as soon a new release of Dash to Dock reached the GNOME Shell extensions website. This would bypass all our QA & security procedures and checks (Ubuntu Desktop is supporting it and you have regular bug fixes and security updates) by enabling another source of update. Once people update from the website, it’s in their local user directory and no system update can override this, potentially having a stalled version they installed, or potentially a newer, incompatible version. An online extension without multiple versions tracking doesn’t allow us to control that.

I guess RHEL should a similar problem shipping gnome-classic by default, made of system extensions, which can be equally overriden by user's update (or even be prompted to upgrade via GNOME Software!) and bypassing QA, security and such.

We workarounded it in Ubuntu 17.10 by not shipping those extensions (having little value compared to upstream dash to dock or KStatusNotifier one) on However, it means that anyone could upload a version and own our ubuntu systems. Discussion with the extensions website team is on the way to prevent that by either updating an empty extension that we never update (suboptimal) or preventing upload to our namespace.

Also, the support for system extensions is quite sparse: the "State" object in GNOME Shell is a mix of status, availability and error (See, and miss some properties like "it's a system extension part of a mode". The consequence is that GNOME Tweaks/gnome-shell-extension-prefs are mostly reporting incorrect status being based on the API or gsettings enabled-extensions key: You are presented with a switch stating the extension part of a mode isn't enabled, and enabling/disabling it doesn't do anything. They are only basing on the gsettings key, while the switch shouldn't be sensitive.

I think we can fix all of this at the same time.

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.

I'm happy to have a deeper look and work on this if the global approach has general conscensus. Happy as well to discuss any other thoughts/ideas fullfilling those requirements.


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