On Mon, Aug 15, 2022 at 09:54:51AM +0200, Jan Engelhardt wrote:
On Monday 2022-08-15 09:24, Richard Biener wrote:
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.
Workaround: have the different variants conflict ...
That would probably sort of work, except rpm/zypper are really bad at resolving such complex dependencies. Already seen a lot of ugliness with kernel variants.
glibc.ppc64le.rpm and glibc.x86_64.rpm already conflict in practice without any additions just because they share files in the same location (/lib64/libc.so.6 and /lib64/libc.so.6).
Which is broken. There is no reason to not have both glibc.ppc64le.rpm and glibc.x86_64.rpm, they provide completely different feature. It also randomly does not conflict with glibc.armv7l or glibc.ppc for no real reason.
Secondly, the autodependencies should be rewritten, from
$ rpm -q --provides glibc ld-linux-x86-64.so.2()(64bit) i586$ rpm -q --provides glibc ld-linux-x86-64.so.2
to
ld-linux-x86-64.so.2()(x86_64) i586$ rpm -q --provides glibc ld-linux-x86-64.so.2()(i586)
why? That would make it difficult to use a library as dependency the user would be able to choose from x86-64-v[123]?
Yes, you are right. But my thought here was that
perhaps we should make sure you can't accidentally mix *totally incompatible* RPM deps (such as installing libfoo1.ppc64le on a glibc.x86_64 system)
Why shouldn't you? Just include glibc.ppc64le as well. Yes, it should not be enabled by default, and if you do enable it you should make sure you do not install any vital system tool as non-native binary because you won't be able to boot otherwise but other than that non-native tools are perfectly usable.
before even tackling the one-direction-is-compatible characteristic of ({somearch, somearchv2}).
Architecture 'version' is nonense. It's just random set of unrelated features that CPU vendors sometimes pick to include, sometimes not. x86 CPUs manufactured last year are not even all x86_64-v3. Most may have most of the CPU features that were arbitrarily picked as 'v3' but not all of them have all. There is similar problem with ppc64le definition - at its inception IBM arbitrarily decided that ppc64le platform compliant systems should have HTM, and now Power10 does not have it although it has a number of other features not available at the time so it's technically not a compilant ppc64le platform. Thanks Michal