Bug#1030683: gnome-shell-extensions-extra: unmaintainable
On Fri, 10 Feb 2023 at 13:12:35 +0200, Adrian Bunk wrote: > Assuming package dependencies ensure that a new gnome-shell will result > in removal of incompatible extensions (which they do, if extension maintainers package extensions the same way the GNOME team does) > a standalone src+bin package > would give the user the option to defer the upgrade , but the aggregated > package would silently drop the incompatible extension leaving the user > without a required/wanted extension. Yes, that's a good description of my reasoning. As a user of testing/unstable/experimental, you might well want to defer upgrading gnome-shell until you've had a chance to either find alternatives to extensions that you consider to be an important part of your workflow, or help to make those extensions compatible with the new Shell yourself. smcv
Bug#1030683: gnome-shell-extensions-extra: unmaintainable
On Thu, Feb 09, 2023 at 10:58:00PM +0100, Daniel Baumann wrote: >... > ..I don't think for this case it matters whetever an extension is part > of an aggregated package or not: > > * if it's a standalone src+bin package, the extension would have an RC > bug and would eventually be removed from testing until it's fixed. > > * if it's part of an aggregated package, the extension would be > dropped from the aggregated package until it's fixed. > > so, basically same result from a testing users point of view wrt/ > availability of the extension in the archive. Package removal is often something where a user will manually check why it gets removed. Assuming package dependencies ensure that a new gnome-shell will result in removal of incompatible extensions, a standalone src+bin package would give the user the option to defer the upgrade , but the aggregated package would silently drop the incompatible extension leaving the user without a required/wanted extension. > Regards, > Daniel cu Adrian
Bug#1030683: gnome-shell-extensions-extra: unmaintainable
Hi Simon, On 2/9/23 14:50, Simon McVittie wrote: > 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? yes, that's correct. > 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. absolutely, yes; however.. > 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. ..I don't think for this case it matters whetever an extension is part of an aggregated package or not: * if it's a standalone src+bin package, the extension would have an RC bug and would eventually be removed from testing until it's fixed. * if it's part of an aggregated package, the extension would be dropped from the aggregated package until it's fixed. so, basically same result from a testing users point of view wrt/ availability of the extension in the archive. Regards, Daniel
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 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
Bug#1030683: gnome-shell-extensions-extra: unmaintainable
Hi Jeremy On 2/9/23 13:15, Jeremy Bícha wrote: > I am lowering the severity of this bug to allow these extensions to > reach Debian 12. thanks you, that is very reasonable as it gives us a bit more time. please let me re-iterate that I'm perfectly fine with whatever consensus is reached between ftp-master and gnome-team. even letting it migrate now, if the consensus is different later on, it can always be removed before the release. > 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. how about this: if the package would depend on (e.g.) 'gnome-shell >> 43 << 44', then your requirement would be satisfied, right? and it would be my burden as the maintainer that I'll need to ensure that all individual extensions work with 43 at the same time. the the more technical things, please note that I'm entirely neutral to whatever way it's going to be packaged.. just providing some inputs. > You are micro-optimizing. [...] But I do not foresee Debian ever having 75 > source packages for GNOME Shell extensions. data point: just noticed that gimp-plugin-registry is also bunding the extensions like this package. > Does Debian have the latest version of the vertical-workspaces > extension? It's not possible to answer that with this combined > package. for the binary package: would a versioned provides satisfy this case? > The maintainer did not use multiple tarballs here (which admittedly is > a bit complicated to set up initially). right, didn't want to do "all of the things at once" :) > GNOME, the upstream maintainer for gnome-shell-extensions, has a right > to define what is GNOME. totally agree; hence the questions for suggestions - happy to rename it to whatever suits best. > 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. ...or (for completness sake) needing me to fix them myself :) Regards, Daniel
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 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.
Bug#1030683: Fwd: Bug#1030683: gnome-shell-extensions-extra: unmaintainable
fwd, seems not to have made it to the bts Forwarded Message Subject: Re: Bug#1030683: gnome-shell-extensions-extra: unmaintainable Date: Tue, 7 Feb 2023 00:49:42 +0100 From: Daniel Baumann Reply-To: m...@daniel-baumann.ch To: Jeremy Bícha CC: Thorsten Alteholz , 1030...@bugs.debian.org, Thorsten Alteholz Hi Jeremy, first of all: I'm the user of the extensions I've uploaded, so I care that they are "apt install"-able and just followed what I've been told to comply and make that possible.. I'll happily adjust the packaging again to whatever is the consense here. On 2/6/23 23:55, Thorsten Alteholz wrote: >> - There is a namespace concern. Sorry, didn't mean to intrude. I've used what seemed most sensible to me. Do you have any suggestions/ preferences to what I should rename it to? Regards, Daniel
Bug#1030683: Fwd: Bug#1030683: gnome-shell-extensions-extra: unmaintainable
fwd, seems not to have made it to the bts Forwarded Message Subject: Re: Bug#1030683: gnome-shell-extensions-extra: unmaintainable Date: Mon, 6 Feb 2023 17:01:27 +0100 From: Daniel Baumann Reply-To: m...@daniel-baumann.ch To: Jeremy Bícha , Thorsten Alteholz CC: 1030...@bugs.debian.org, Thorsten Alteholz Hi Jeremy On 2/6/23 14:22, Jeremy Bícha wrote: > gnome-shell-extensions-extra is a new collection of 6 different source > packages bundled into a single source package with a single binary > package. I've uploaded them packaged as separate src packages producing the usual binary package as all the other gnome-shell extensions are packaged, however, ftp-master insisted doing one source package producing one binary package. Thorsten: please advise on how to go forward. Should I re-upload them as seperate packages again and we remove gnome-shell-extensions-extras? Regards, Daniel
Bug#1030683: gnome-shell-extensions-extra: unmaintainable
Hi everybody, - There is no upstream that bundles these extensions together like this. there is almost no upstream who creates Debian packages and yet Debian does it. - There is no unifying theme for why these extensions are included and why others are not included, except perhaps these extensions are useful to the Maintainer. 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. - 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. - It is not easily possible for the Security Team to determine whether security bugs and fixes apply to this package. There are lots of packages where the CVE description from Mitre does not match the package name in Debian. So the Security Team already has to deal with this for other packages. I assume for that reason check_new_issues from the security tracker does exist to support them with this problem. 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. - 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. - 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? 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? On Mon, 6 Feb 2023, Daniel Baumann wrote: Thorsten: please advise on how to go forward. Should I re-upload them as seperate packages again and we remove gnome-shell-extensions-extras? Daniel: the only valid argument from Jeremy is about apt not showing the upstream version. But I don't think this justifies a penalty for all Debian users. So no, please keep gnome-shell-extensions-extras. Regards, Thorsten
Bug#1030683: gnome-shell-extensions-extra: unmaintainable
Source: gnome-shell-extensions-extra Version: 20230205-2 Severity: serious Justification: unsupportable Tags: sid bookworm X-Debbugs-CC: debian-gtk-gn...@lists.debian.org gnome-shell-extensions-extra is a new collection of 6 different source packages bundled into a single source package with a single binary package. - There is no upstream that bundles these extensions together like this. - There is no unifying theme for why these extensions are included and why others are not included, except perhaps these extensions are useful to the Maintainer. - It is not possible to use apt to determine the upstream version number for these extensions. - It is not possible to use uscan to check for new upstream releases - It is not easily possible for the Security Team to determine whether security bugs and fixes apply to this package. - 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". - Twice per year, GNOME releases a new major version of GNOME Shell which breaks all GNOME Shell extensions until they are manually updated for the new release. It upsets users when their packaged GNOME Shell extensions silently no longer work because of a GNOME Shell update. Therefore, the Debian GNOME team has a best practice of specifying the GNOME Shell versions an extension works with, in the package dependencies set in debian/control for each extension so that apt will warn the user of extensions that are not compatible yet with the new release. 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. This becomes an unmaintainable mess when a new major GNOME Shell version is prepared for Debian Unstable. 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 On behalf of the Debian GNOME team, Jeremy Bícha
