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(a)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):
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to
packaging-leave(a)lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure