Gnome extensions, updates, and testing

Help
6

Some random thoughts:

  • First of all I’d like to highlight how much of all of this is just hacking around the limitations of extensions.gnome.org. Especially the metadata pinning in the extensions.json is something that I really dislike.
  • Similarly, all our extensions are currently not built from source. Since JavaScript is an interpreted language, this doesn’t make a huge difference conceptually. However it means that our “sources” don’t match the upstream’s sources, they instead match upstream releases. This makes patching automatically packaged extensions so annoying: You either have to add a manual package (which is just boilerplate on most extensions, except those that use TypeScript or so), or you have to adapt your patch to the slightly different source. Upstream has plans for having a more unified build pipeline across extensions, but it’s probably going to take a long time and until then there’s not really much we can do.
  • Personally, my preferred solution would be to simply have users disable-extension-version-validation, because it introduces the least maintenance overhead. It also does not put us at risk of implicitly breaking things (the user would be more clear about the fact that it’s their fault ^^). But I understand your motivation for a nixpkgs solution.

Now onto the question:

There are many possible locations for patching the information in the pipeline. We first of all need to tell our packaging that the extension actually supports GNOME 41. I’d suggest an attribute override to extensions.json. Then, we also need to tell GNOME the same in the metadata.json. Although that file is technically contained in extensions.json, overriding it there would not be a good idea: it is hex encoded in a string and modifying it would give us hash mismatch headaches again. I think a better way would be to inject a patch or a fixup hook to that file in an override of the extension.

Then, there’s the problem of maintainability. We would want to be informed somehow that the extension now supports that GNOME version upstream, and that we thus have to remove our patch again. I don’t have any ideas off the top of my hat for this.

You see, it’s technically possible, but it won’t be easy for sure. I wouldn’t be against it provided that maintainability is preserved, but I would prefer some solution that cooperates with GNOME to improve the general situation (e.g. to make sure extensions are already up to date when GNOME updates).

3 Likes