On 6/12/24 14:07, Ben Cotton wrote:
Yeah, maintaining that long-term seems like a bad idea. [...] But it
would at least buy us some time so that we don't end up with the
"surprise, you can't use this release on your hardware if you want to
use QEMU!" situation.
The root cause seems to be the QEMU upstream's switch to x86_64_v2 ABI
without a backwards compatiblity. If the software is not compatible with
a given hardware, it just should not install; Fedora should not be stuck
at an obsolete version for everyone, or expected to backport
alternatives, or be blamed for the breakage on old systems.
I am an old man, but even I understand that sometimes backwards
compatibility has to go if there are tangible benefits to breaking
changes and no practical workarounds, whether it's 32-bit-only support,
or X11, or QEMU; I accept it even if I am personally affected.
To prevent the surprise, I wonder if Fedora could detect and warn for
old hardware :
"The future upstream changes to QEMU will require x86_64_v2
hardware, making it incompatible with your system"
before the upstream changes arrive. After that, I like Neal's suggestion
of declaring it via RPM attributes, and making it
non-installable/non-upgradeable on old architectures. I guess people
will have to decide then if they uninstall or lock out updates with
'versionlock' or '--skip-broken'. I understand that locking updates
would still eventually result in nonfunctional QEMU because of diverging
dependencies.
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
