Simon Lees <sflees@suse.de> writes:

On 8/1/22 18:17, Dan Čermák wrote:

...

Simon Lees <sflees@suse.de> writes:

...

On 7/28/22 23:40, Marius Kittler wrote:

...

Am Donnerstag, 28. Juli 2022, 15:30:15 CEST schrieb Neal Gompa:

...

To the best of my knowledge, no community distribution has elected to move to a higher level yet. It has been brought up a few times in Fedora and Arch, but as far as I know, the change hasn't happened yet in a way that eliminates x86_64-v1 in these distributions.

When I've been following-up Arch Linux correctly, they've decided to provide x86_64-v3 packages *in addition* to their existing x86_64 packages (which will remain unaffected for now). The option to make x86_64-v2 the new baseline (replacing existing x86_64 packages) was also on the table but they decided against it because x86_64-v2 would bring almost no benefit, at least not enough to justify the hardware requirement. (Note that providing x86_64-v3 packages has not been carried out yet. It looks like they want to focus on their build automation first. Not a concern for openSUSE, though.)

I suppose this decision makes most sense. No users on old hardware will be negatively affected and users with newer hardware can switch to x86_64-v3 packages.

The simplest way of achieving this, that would on the other hand use the most build resources would be to add a new arch "x86_64-v3" which would leave people with a choice. Whether we have the spare build power for this would be the main question.

I think this is the best way forward: rebuild a performance critical subset of the packages for x86_64 v3 or v2 and leave the rest at v1. Unfortunately this requires support for sub-architectures in rpm, which is afaik not yet implemented (and iirc upstream was hesitant to add support for that).

Yeah I think what your suggestion makes most sense if its technically doable, although that also involves figuring out which packages would benefit most. My suggestion would get around that by using a rather blunt instrument approach in rebuilding everything so in the same way we have a "armv6l" and "armv7l" we have "x86_64" and "x86_64_v3" or alternatively "x86_64_legacy". In this approach we end up building everything twice hence being rather blunt, and either we then encourage most users to move to the "x86_64_v3" repos or we make it very clear that x86_64 is moving to v3 and users with insufficient hardware need to move to the "x86_64_legacy" repos, we could even possibly look at putting a warning in zypper to not allow incompatible systems to upgrade once we switch to v3. But as I said in my previous email this approach would require obs having the build power. If ALP ends up going to V3 we could also use this approach to build community editions with V1.

Yes this is certainly an option, but this nearly double the load on our x86_64 workers for a marginal benefit for the majority of the packages. And another issue: it will double the storage requirements for the mirrors as well. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman