My understanding from the changelog is that the maintainer Daniel Baumann first packaged a bunch of GNOME Shell extensions according to the GNOME team's usual convention (one package per independent upstream project), and then was asked by the ftp team to replace them with a single package collecting together multiple unrelated extensions?
If that's the case, then I would have preferred Daniel's original packaging: that would have been a better fit for how the GNOME team and other Debian contributors normally handle GNOME Shell extensions. On Thu, 09 Feb 2023 at 07:15:03 -0500, Jeremy Bícha wrote: > On Mon, Feb 6, 2023 at 6:30 PM Thorsten Alteholz <[email protected]> wrote: > > At the moment there are only packages called gnome-shell-extension-* in > > the archive. The combined package is called gnome-shell-extensions-* > > I don't see a namespace concern here. > > If the upstream maintainer for gnome-shell-extensions decides to > create a project, gnome-shell-extensions-extra, we will have a name > conflict. And we would need to add an epoch to the package because > this package is using a large number for the "upstream" version. > GNOME, the upstream maintainer for gnome-shell-extensions, has a right > to define what is GNOME. This was the main concern that occurred to me on seeing gnome-shell-extensions-extra leave NEW. We already have gnome-shell-extensions and gnome-themes-extra, both of which are maintained by GNOME upstream under those names, so gnome-shell-extensions-extra seems like a naming scheme they're reasonably likely to use at some point. (In case the ftp team are not aware: gnome-shell-extensions is not just a collection of extensions for GNOME Shell, it's the set of "official" extensions released by the GNOME project alongside Shell itself.) The name is also rather non-indicative. If I understand correctly, the criteria for inclusion in this package go something like: the extension wasn't already packaged, and is something that Daniel wants (or possibly something that Progress Linux wants). That doesn't seem a particularly coherent theme for a collection of extensions, or particularly discoverable for users who want to use those extensions. I don't want to make users guess whether the extension they want is in gnome-shell-extensions-daniel, gnome-shell-extensions-smcv, gnome-shell-extensions-jcc or somewhere else! Again, I'd prefer it if these extensions were one-per-package. I think there are important differences between Shell extensions and other very small packages: Shell extensions are directly user-facing (not just dependency libraries, so discoverability matters), they require a specific version of gnome-shell, and they need changes every GNOME cycle, which can either be trivial (a metadata update), very intrusive (rewriting the code to be compatible with GNOME Shell changes), or anything in between. Or, if the ftp team is going to insist that "small" third-party Shell extensions get collected into one bundled package, then I think that package needs to be maintained in the GNOME team (Daniel would be welcome to be an Uploader, or even its primary uploader) so that we can do coordinated uploads of mutter + gnome-shell + gnome-shell-extensions + that new package every 6 months. If the ftp team insist on that model, then I think only small extensions with relatively trivial code and no extra dependencies should be aggregated into that package, to minimize how often an extension has to be dropped from it without warning. For example, gnome-shell-extension-hide-activities or gnome-shell-extension-autohidetopbar could maybe be aggregated into a larger package if the ftp team insist, but not things like gnome-shell-extension-dash-to-panel (which tends to need significant changes per GNOME version if I remember correctly) and also not gnome-shell-extension-hamster (which has additional dependencies). Even if we adopt a single package for a bundle of unrelated extensions into the GNOME team, I'm having difficulty thinking of an indicative name for that package that would help users to realise that it's an appropriate place to look for several unrelated smaller extensions. gnome-shell-extensions-misc-small? gnome-shell-extensions-assorted? Some upstreams would probably suggest gnome-shell-extensions-contrib, but the word contrib has a different meaning in Debian. > All extensions need a minor change for compatibility. Some extensions > will need major changes. You will force the maintainer of this package > to either drop incompatible extensions with no warning to people > running Unstable or Testing, or hold back all the bundled extensions > because one or more are not yet compatible. If one of the bundled extensions isn't ready for a new GNOME Shell and can't easily be ported, then "hold back all the bundled extensions" isn't really an option: we are not going to delay a GNOME Shell upgrade just because an extension isn't keeping up, because GNOME Shell is much more important to the distribution than any individual extension. The options would be to drop incompatible extensions from the bundled package, or to remove the entire bundled package from testing until it can be made compatible again. For additional context for the ftp team, who might not be aware: the reason why we need intrusive changes to GNOME Shell extensions so often is that GNOME Shell intentionally does not have a stable extension API (because if it did, that would constrain its UI to only change in ways that don't invalidate the extension API). Don't think of them as like GStreamer plugins; think of them as more like out-of-tree kernel modules or the old xul-ext- packages for Firefox. This makes them very powerful, at the cost of inability to expect forward-compatibility. smcv
