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@xxxxxxxxxxxxxxxxx> wrote:
See this Ask Fedora topic: https://ask.fedoraproject.org/t/fedora-34-extensions-installed-from-dnf-disabled-after-upgrade-to-fedora-35/18017
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@xxxxxxxxxxxxxxxxx>
Fedora Project Leader
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Best regards / S pozdravem,
František Zatloukal
Quality Engineer
Red Hat
_______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
