Dne 12. 06. 24 v 19:14 Neal Gompa napsal(a):
On Wed, Jun 12, 2024 at 4:00 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:IOW, if [when] we rebase Fedora to the next QEMU upstream release, users with older x86_64 hardware would likely be unable to run QEMU, from F41 onwards, unless some TBD action is taken. Thus I'm wondering whether Fedora has any policy or guidance on handling such a situation both in general, and more specifically for "critical path" packages, if that difference is relevant ? The packaging guidelines aren't especially explicit about this situation, unless I've missed something beyond the "compiler flags" and "architecture support" sections.Absent a project-wide decision to move to the newer baseline, I think the best approach we can take would be to find some way to communicate to the user that the software isn't usable. In the case of Qemu, does the application report an error or crash if it's run on hardware without the requisite baseline?I've not tested, but I would expect it to crash attempting to execute an illegal instructionOK, that's a situation that will lead to annoying and unresolvable bug reports. Would it be possible to put something in place that would check processor capabilities early in execution before hitting any of the affected instructions?Build the package as x86_64_v2 instead of x86_64. Not lying about the architecture will ensure that we don't bypass RPM's own compatible architecture check.
So what is the reason to not treat x86_64_v2 as different arch then x86_64_v{1,3}. Why we keep having this discussion instead of fire one more build? Users would need to choose v1 / v2 / v3 ISO but what else?
Vít
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
