On Wed, Jun 12, 2024 at 9:15 PM Przemek Klosowski via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. This is supported since RPM 4.19, so we should just do it. We may also want to start having a conversation about moving to x86_64-v2 RPM arch for x86_64 across the board if we're going to start encountering stuff like this. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
