Re: Bug#1030683: gnome-shell-extensions-extra: unmaintainable
Control: severity -1 important
I am lowering the severity of this bug to allow these extensions to
reach Debian 12. I do still think this is RC for Unstable because of
how it breaks user experiences when new GNOME major releases (like 43
to 44) happen but that won't happen for Stable. A major factor in
downgrading this bug is that the Freeze deadline is coming very
quickly and it seems like there isn't time to handle this issue more
appropriately.
I'm CCing the Debian GNOME packaging mailing list. See
https://bugs.debian.org/1030683 for earlier comments.
On Mon, Feb 6, 2023 at 6:30 PM Thorsten Alteholz <debian@alteholz.de> wrote:
> This is a good point. Maybe all other extensions could be put into this
> package as well?
> From my point of view all similar packages, where the metainformation is
> bigger than the data, should be somehow combined into one package.
> Another good candidate to add to gome-shell-extensions-extra would be
> gnome-shell-extension-hide-activities.
>
> > - It is not possible to use apt to determine the upstream version
> > number for these extensions.
>
> From a user point of view I don't care about versions. But I do care
> about processing time of apt.
You are micro-optimizing. Debian has more than 60,000 binary packages.
Bundling 6 packages together will not make apt noticeably faster than
packaging them the same way we package everything else. Even if you
did this for 75 extensions, you're still only affecting 1/1000 of the
binary package count. But I do not foresee Debian ever having 75
source packages for GNOME Shell extensions.
> > - It is not possible to use uscan to check for new upstream releases
>
> This is not true. uscan can handle multiple upstream tar files.
> The node people are using this feature for exact this reason: combine
> several small packages into one bigger one.
Yes, it is possible for uscan to handle multiple upstream tarballs.
It is not possible for uscan to intelligently report when any
particular tarball in the set has a new release.
Does Debian have the latest version of the vertical-workspaces
extension? It's not possible to answer that with this combined
package.
The maintainer did not use multiple tarballs here (which admittedly is
a bit complicated to set up initially).
> Anyway, looking at the list of CVEs there are seven CVEs for package
> gnome-shell since 1999 and none for any gnome-shell-extension-*.
> This argument sounds like a pretended one.
I am willing to say that I don't remember seeing any security fixes
for published GNOME Shell extensions so my security maintenance
concern is unlikely.
> > - There is a namespace concern. Since the GNOME project officially
> > maintains something called "gnome-shell-extensions", it is possible
> > they may eventually produce something called
> > "gnome-shell-extensions-extra" as they have done with
> > "gnome-themes-extra".
>
> 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.
> > - Twice per year, GNOME releases a new major version of GNOME Shell
> > which breaks all GNOME Shell extensions (...)
> > I personally verified that this was in place for all the independently
> > packaged extensions in Debian Testing for the GNOME 44 release. This
> > package does not have these relations in debian/control and cannot.
>
> You just have a versioned Depends: on gnome-shell in debian/control. Why
> shouldn't this be possible for a combined package, when all extensions
> are broken?
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.
> > I am initially filing this bug as Serious because I believe the
> > current packaging is unsupportable and violates paragraph 5(a) of
> > https://release.debian.org/testing/rc_policy.txt
>
> This paragraph relates to policy 2.2.1. This is basically about
> dependencies outside of main, policy requirements and bugs within the
> package. Can you please be a bit more verbose where you see bugs?
> Shouldn't they be reported upstream?
The bug I filed here is a Debian packaging bug.
Debian Policy is a bit vague about what it means for a package to be
unsupportable.
These GNOME Shell extensions are independent releases. They do not
have the same upstream maintainer or upstream release schedule or
upstream version numbering or anything.
You would have a better argument to put all of GNOME Core in a single
binary package because at least there is a single organization that
can point to a single group of things they release as "GNOME 42.7".
[1] But we don't do that because Debian decided a very long time ago
to not bundle everything into as few packages as possible. I think
Debian Policy isn't very specific on this point because it was just a
universally accepted fundamental principle of Debian packaging.
[1] https://discourse.gnome.org/t/gnome-42-7-released/12741
Thank you,
Jeremy Bícha
Reply to: