Control: tags -1 moreinfo On Thu, 2016-05-19 at 12:06:58 +0100, Wookey wrote: > Package: dpkg > Version: 1.18.7 > Severity: wishlist
> There is a new ABI for arm64 which is the equivalent of x32 on amd64. > It uses the armv8 instruction set for a 32-bit ABI (32-bit > instructions, longs and pointers). Generally referred-to is 'ILP32' in > comparison to the 'LP64' standard arm64 ABI. > > This is only expected to be used in quite rare circumstances, but we > do want to make it possible to build in a debian or debian-derived > context, which needs dpkg support. As I mentioned on IRC at the time, I see several problems here: > Attached is a patch to provide that. It also add existing arm64 > big-endian so that people can 'easily' build that too if need be. > > diff -Nru dpkg-1.18.1/cputable dpkg-1.18.1+nmu1/cputable > --- dpkg-1.18.1/cputable 2015-05-22 01:17:44.000000000 +0100 > +++ dpkg-1.18.1+nmu1/cputable 2015-06-18 02:12:22.000000000 +0100 > @@ -21,6 +21,8 @@ > armeb armeb arm.*b 32 big > arm arm arm.* 32 little > arm64 aarch64 aarch64 64 little > +arm64be aarch64_be aarch64_be 64 big > +arm64ilp32 aarch64 aarch64_ilp32 32 little > +arm64ilp32be aarch64_be aarch64_be_ilp32 32 big > avr32 avr32 avr32 32 big > hppa hppa hppa.* 32 big > m32r m32r m32r 32 big The convention for endianness disambiguation has been «el» or «eb», I'd appreciate consistency here. I also updated the FAQ to clarify this at the time. <https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_a_new_dpkg_architecture.3F> Then there's the ossue with the ilp32 stuff. First you are usig the same name as the normal arm64 architectures, which in a way makes sense because this is simply part of the ABI. But then this means to me the upstream name is wrong, and it should not be encoded in the CPU name but in the ABI name. Which we also covered on IRC. In any case, marking as moreinfo, until these are clarified and/or fixed. Thanks, Guillem
