Re: Bug#1030683: gnome-shell-extensions-extra: unmaintainable
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 <debian@alteholz.de> 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
Reply to: