It's like Haskell's overlay system, but way more primitive. We simply pre-define some
package overrides that are required for an automatically packaged extension to work.
Ideally, all (or almost all) currently manually pacakged extensions will work this way.
Since these are mostly just a few lines each, there is no need to split this up into a
lot of small files.
"system-monitor@paradoxxx.zero.gmail.com" is manually packaged,
"System_Monitor@bghome.gmail.com" is automatically packaged.
Both have the extensionPortalSlug "system-monitor", but the former
gets shadowed by the latter.
Their keys are now not used directly. Instead, we go the standard route of mapping to the
UUID in order to apply the rename procedure. This makes sure the manual override always does
the correct thing, and also gives us more consistency overall.
They should have gnome-shell-extension prefix like most other extension packages.
This is what other distros listed on Repology use so Repology will be able to unify them.
Exception is chrome-gnome-shell, which is estabilished under that name.
An automatic way to do this that scales up and requires little manual intervention is really needed. It works by scraping extensions.gnome.org with a python script, that writes all relevant information into the `extensions.json`. Every attribute of besaid file can be built into a package using `buildShellExtension`.
Extensions are grouped by GNOME Shell version for practical reasons. Only extensions for GNOME 40 and 3.38 were added, as we don't support legacy GNOME versions.
The extensions are exposed as an attrset, `pkgs.gnome40Extensions` and `pkgs.gnome38Extensions` respectively. The package name of each extensions is generated automatically from its UUID.
The attribute `pkgs.gnomeExtensions` contains the officially packaged and supported extensions set. It contains all the automatically packaged extensions for the current GNOME Shell version, which are overwritten by manually packaged ones where needed. Unlike gnomeXYExtensions, the names are not UUIDs, but automatically generated human-friendly names. Naming collisions – which are tracked in collisions.json – need to be manually resolved in the `extensionRenames` attrset.
