---------- Forwarded message ---------
From: David Powell
Date: Thu, 18 Aug 2022 at 19:28
Subject: Re: x86_64 architecture level requirements, x86-64-v2 for openSUSE
Factory
To: Neal Gompa
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 wrote:
On Thu, Aug 11, 2022 at 10:59 AM Jan Engelhardt 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!