Should we have rpm package policies tying extension packages to the GNOME versions they'll work with?
See this Ask Fedora topic: https://ask.fedoraproject.org/t/fedora-34-extensions-installed-from-dnf-disa...
In short, some rpm-packaged GNOME Shell extensions don't work with the GNOME Shell we are shipping, but this isn't expressed in the dependencies.
I looked at the package which triggered the question, and:
$ rpm -qRp gnome-shell-extension-sound-output-device-chooser-39^1.8c90ed0-1.fc35.noarch.rpm gnome-shell-extension-common python3 rpmlib(CaretInVersions) <= 4.15.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1
and
$ rpm2cpio gnome-shell-extension-sound-output-device-chooser-39^1.8c90ed0-1.fc35.noarch.rpm |cpio -i --quiet --to-stdout './usr/share/gnome-shell/extensions/*/metadata.json'|jq '."shell-version"' [ "3.32", "3.34", "3.36", "3.38", "40" ]
Would it make sense to have an automatic dependency generator which requires gnome-shell to be one of those versions? (Or conflicts with gnome-shell which is _not_ those versions?)
On Fri, Nov 12, 2021 at 10:25 PM Matthew Miller mattdm@fedoraproject.org wrote:
See this Ask Fedora topic: https://ask.fedoraproject.org/t/fedora-34-extensions-installed-from-dnf-disa...
In short, some rpm-packaged GNOME Shell extensions don't work with the GNOME Shell we are shipping, but this isn't expressed in the dependencies.
I looked at the package which triggered the question, and:
$ rpm -qRp gnome-shell-extension-sound-output-device-chooser-39^1.8c90ed0-1.fc35.noarch.rpm gnome-shell-extension-common python3 rpmlib(CaretInVersions) <= 4.15.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1
and
$ rpm2cpio gnome-shell-extension-sound-output-device-chooser-39^1.8c90ed0-1.fc35.noarch.rpm |cpio -i --quiet --to-stdout './usr/share/gnome-shell/extensions/*/metadata.json'|jq '."shell-version"' [ "3.32", "3.34", "3.36", "3.38", "40" ]
Would it make sense to have an automatic dependency generator which requires gnome-shell to be one of those versions? (Or conflicts with gnome-shell which is _not_ those versions?)
I don't see a reason why not. Having a dependency generator that leverages a "gnome-shell(abi)" dependency to link the two would make sense. Potentially we'd want to check and fail the build if non-matching versions exist through a buildroot policy too?
Overall, I think it's a good idea to add some dependency generator. This should also cause FTI tickets to be auto-created once an extension becomes un-installable which should give the maintainers time to get in touch upstream and/or fix it by hand.
On the other hand though, I barely remember that the compatibility check by GNOME was re-introduced with GNOME 40 and it may be disabled by default in the future again.
Matthew, can you ask the GNOME folks if they have any plans about this? If the compatibility enforcement was to be disabled again, this "may not" (I am not 100 % sure about this) be necessary at all (the extensions worked throughout different GNOME versions before 40 just fine in the most cases, without any fixing and tweaking)?
On Fri, Nov 12, 2021 at 2:50 PM Matthew Miller mattdm@fedoraproject.org wrote:
See this Ask Fedora topic: https://ask.fedoraproject.org/t/fedora-34-extensions-installed-from-dnf-disa...
In short, some rpm-packaged GNOME Shell extensions don't work with the GNOME Shell we are shipping, but this isn't expressed in the dependencies.
I looked at the package which triggered the question, and:
$ rpm -qRp gnome-shell-extension-sound-output-device-chooser-39^1.8c90ed0-1.fc35.noarch.rpm
gnome-shell-extension-common python3 rpmlib(CaretInVersions) <= 4.15.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1
and
$ rpm2cpio gnome-shell-extension-sound-output-device-chooser-39^1.8c90ed0-1.fc35.noarch.rpm |cpio -i --quiet --to-stdout './usr/share/gnome-shell/extensions/*/metadata.json'|jq '."shell-version"' [ "3.32", "3.34", "3.36", "3.38", "40" ]
Would it make sense to have an automatic dependency generator which requires gnome-shell to be one of those versions? (Or conflicts with gnome-shell which is _not_ those versions?)
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Nov 15, 2021 at 01:40:39PM +0100, Frantisek Zatloukal wrote:
Matthew, can you ask the GNOME folks if they have any plans about this? If the compatibility enforcement was to be disabled again, this "may not" (I am not 100 % sure about this) be necessary at all (the extensions worked throughout different GNOME versions before 40 just fine in the most cases, without any fixing and tweaking)?
Sure, or some of the folks on the desktop list here who might be already in the know could chime in. :)
I kind of think it'd be useful to at least _alert_ maintainers and ask them to test and update (either to a new version, or just patch the compat list if the current one works), no matter what that setting ends up as.
On Mon, Nov 15, 2021 at 01:40:39PM +0100, Frantisek Zatloukal wrote:
On the other hand though, I barely remember that the compatibility check by GNOME was re-introduced with GNOME 40 and it may be disabled by default in the future again.
Matthew, can you ask the GNOME folks if they have any plans about this? If the compatibility enforcement was to be disabled again, this "may not" (I am not 100 % sure about this) be necessary at all (the extensions worked throughout different GNOME versions before 40 just fine in the most cases, without any fixing and tweaking)?
It seems like the upstream consensus* is that it's better to keep the check, so that someone at least looks and does the update. And honestly, I think that's completely reasonable for extensions that we've chosen to specifically make available in RPM form as part of the Fedora Linux distro.
But it'd be nice to have tooling (both upstream and in Fedora) to help extension developers and maintainers. I don't know how much capacity we have for openqa testing of something like this, or what GNOME can offer.
* https://discourse.gnome.org/t/plans-for-extension-validation-setting/8107 and https://discourse.gnome.org/t/unable-to-download-updates-from-extentions-gno...
Matthew Miller mattdm@fedoraproject.org wrote: ...
But it'd be nice to have tooling (both upstream and in Fedora) to help extension developers and maintainers.
The workstation working group discussed this yesterday, and agreed that it would be good to have a dependency generator for packaged gnome-shell extensions. We have a tracking issue for this, here:
https://pagure.io/fedora-workstation/issue/257
If anyone would like to help implement this, we'd love your input!
Allan
desktop@lists.stg.fedoraproject.org
-
Allan Day -
Frantisek Zatloukal -
Matthew Miller -
Neal Gompa