---------- Forwarded message --------- From: David Powell <achiestdragon@gmail.com> Date: Thu, 18 Aug 2022 at 19:28 Subject: Re: x86_64 architecture level requirements, x86-64-v2 for openSUSE Factory To: Neal Gompa <ngompa13@gmail.com> theres a bigger issue here , not just down to if the actual cpu is v1,v2,v3,v4 , but this split is going to cause the same issues as we have seen on the 32/64 bit issues , that is down to none ( suse repo ) provided code , that may be object code distributed by another party , the end result is you need both sets of libs installed its not always down to older cpu support that is the issue , its if code written for those older cpus can still run , given it may not always be possible to recompile that code , it may be fair to say theres not a lot of v1/v2 chips around , and code written spesificaly for them, i would propose that some cpu capability detection was used , that would if detected install the v3 or above code as a addition to the v1,v2 , libs , or probably better would to have the option to select if you want v1,v2 support installed if you have a v3 , ie an include legacy support option , ok so this i expect makes for more work coding it , but i do feel doing it now and making it part of the system could also be extended to include 32bit legacy libs , in the long term it would make future issues like this resolvable say v5 v6 or whatever comes next ie : include i386 legacy support (hmm ok so not ) include i586 legacy support (but my old eprom programmer app still needs this ) include x86-32 bit legacy support (and old game with no 64 bit supporte uses this) include x86-v1-v2 legacy support ( who knows what apps are going to be left out because they where distributed as precompiled binaries with v1,2 support only )* x86-v3 or above current default conclusion is we only have to look at the number of programs that still need 32bit support to highlight the issues we may face with v1,2 and v3 support , and future such issues maybe v5 ...v9 whatever that future gives , it may be fair to say that dropping cpu support is not going to affect the mass number of users , but it will if v3 only versions drop support for running old code that cannot be recompiled and need old libs , that is a far wider reaching issue that may affect one or more apps that a user NEEDS to run and is not in the suse repos ! i suspect given v3 support is a new higher target that all apps that are non repo distributed binary only 3rd party apps are going to be an issue to all users since they have not been compiled with v3 default support David (achiestdragon) On Thu, 18 Aug 2022 at 09:45, Neal Gompa <ngompa13@gmail.com> wrote:

On Thu, Aug 11, 2022 at 10:59 AM Jan Engelhardt <jengelh@inai.de> wrote:

...

On Thursday 2022-08-11 16:24, Michal Suchánek wrote:

...

...

But then rpm itself doesn't do any magic and will happily install even arm architecture packages to your x86_64 system IIRC.

Considering you can do `rpm --chroot`... and with things like qemu-via-binfmt, could actually *use* the ARM package, it make sense that rpm did not want to impose restrictions. It's a glorified cpio unpacker that keeps a record of all unpacked files in a database. zypper applies the architecture logic (like proposing glibc.i686 on 686-capable x86); that all looks like a good layering design.

...

Unfortunately there is no support for having the required support libraries for multiple architectures.

I see two blockers.

First, arch-specific libraries would have to live in arch-specific

directories,

...

like is the case with /usr/lib/x86_64-linux-gnu on Debian.

Secondly, the autodependencies should be rewritten, from

$ rpm -q --provides glibc glibc = 2.35-6.1 glibc(x86-64) = 2.35-6.1 ld-linux-x86-64.so.2()(64bit) i586$ rpm -q --provides glibc ld-linux-x86-64.so.2

to

glibc = 2.35-6.1 glibc(x86-64) = 2.35-6.1 ld-linux-x86-64.so.2()(x86_64) i586$ rpm -q --provides glibc ld-linux-x86-64.so.2()(i586)

Indeed. In fact, I had proposed such enhancements to the elf autodeps code in RPM quite some time ago[1].

However, it doesn't solve subarch stuff, mostly because it wasn't a thing I had to think about when I wrote it...

[1]: https://github.com/rpm-software-management/rpm/pull/1038

-- 真実はいつも一つ！/ Always, there's only one truth!