[Rpm-maint] [rpm-software-management/rpm] Rework how architectures are handled (Discussion #2140)

[Dan Čermák]

This is related to https://github.com/rpm-software-management/rpm/discussions/2022, but taking it from a different angle

## Background

x86_64 or amd64 has evolved quite a bit over the past decade(s) and new CPUs support a plethora more instructions than the original amd64 variants, leading to potentially higher performance when utilizing these instructions. As of today, there are multiple x86_64 baselines, but the crux is that there were new CPUs being sold in 2021 that did not yet support x86_64v2 and a majority of the CPUs does not support x86_64v3 at all. This means that increasing the required minimum arch to x86_64v2 will cut off too many users and is generally unacceptable by community Linux distributions (see multiple discussions on fedora devel or recently on openSUSE-factory).

Rebuilding the **whole** distro multiple times for x86_64v1 and x86_64v2/v3 is a potential solution, but mostly pointless, as very few packages offer any performance benefit, so this would just cost a **lot** of resources. It would be much better to just rebuild a subset of performance critical packages, e.g. the kernel, glibc, blas, lapack, etc. for both x86_64v1 and x86_64v2, publish both and allow rpm to install it.

## Way forward

I don't know how feasible such an approach is, but I believe that community distributions will need something like this to stay competitive with commercial distributions which can afford to not support older hardware, whereas community distros cannot just drop these nor have the resources to rebuild **everything** multiple times.

@ffesti Told me that architecture handling is quite the mess atm and would need to be reworked. What needs to be done here?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2140
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/2140 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220804/479e0822/attachment-0001.html>