On Thu, Aug 11, 2022 at 10:59 AM Jan Engelhardt
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!