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 <deb...@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
