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?)
Please no! Unless you want to break Rawhide users. The upstream versioning is already quite hostile.
Vít
Dne 12. 11. 21 v 14:49 Matthew Miller napsal(a):
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 agree that we need some mechanism to keep this working, but Requires might indeed be too strict. Would a
BuildRequires >= (the version it wants)
or something help? That way the existing versions would still be in the repo, and maintainers wouldn't easily push new versions that aren't supported.
Disclaimer, I've not yet finished my first tea.
-- Gwyn Ciesla she/her/hers ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 12th, 2021 at 8:30 AM, Vít Ondruch vondruch@redhat.com wrote:
Please no! Unless you want to break Rawhide users. The upstream
versioning is already quite hostile.
Vít
Dne 12. 11. 21 v 14:49 Matthew Miller napsal(a):
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?)
packaging mailing list -- packaging@lists.fedoraproject.org
To unsubscribe send an email to packaging-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/packaging@lists.fedoraproject....
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Nov 12, 2021 at 03:27:17PM +0000, Gwyn Ciesla wrote:
I agree that we need some mechanism to keep this working, but Requires might indeed be too strict. Would a
BuildRequires >= (the version it wants)
or something help? That way the existing versions would still be in the repo, and maintainers wouldn't easily push new versions that aren't supported.
Disclaimer, I've not yet finished my first tea.
It's the opposite problem I'm mostly concerned with. However, this would at least make them FTBFS if they aren't marked as supporting the current GNOME, which would at least clean up the ones that have been lingering for a long time.
Dne 13. 11. 21 v 23:15 Matthew Miller napsal(a):
On Fri, Nov 12, 2021 at 03:27:17PM +0000, Gwyn Ciesla wrote:
I agree that we need some mechanism to keep this working, but Requires might indeed be too strict. Would a
BuildRequires >= (the version it wants)
or something help? That way the existing versions would still be in the repo, and maintainers wouldn't easily push new versions that aren't supported.
Disclaimer, I've not yet finished my first tea.
It's the opposite problem I'm mostly concerned with. However, this would at least make them FTBFS if they aren't marked as supporting the current GNOME, which would at least clean up the ones that have been lingering for a long time.
This would be much preferable.
Vít
Just FTR, this is the upstream ticket relevant to this discussion:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3808
Vít
Dne 12. 11. 21 v 15:30 Vít Ondruch napsal(a):
Please no! Unless you want to break Rawhide users. The upstream versioning is already quite hostile.
Vít
Dne 12. 11. 21 v 14:49 Matthew Miller napsal(a):
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 03:30:32PM +0100, Vít Ondruch wrote:
Please no! Unless you want to break Rawhide users. The upstream versioning is already quite hostile.
... but it seems even more hostile to have users' desktops break on upgrades because of incompatible extensions we've packaged into the distro.
My hope is that there'd be coordination when the newer gnome-shell lands, and the maintainers of these packages (and possible newer co-maintainers too) would test and update (possibly even just with a local metadata.json patch if the extension works unchanged). What's happening now is that no one notices that they need attention. Especially for some of the more obscure ones that happen to be included.
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?
packaging@lists.fedoraproject.org