data/platforms.yml uses x86 as the preferred spelling for the shared ABI of all 32-bit x86 CPUs, and i386 as a compatibility alias.
This makes Appstream almost, but not quite, compatible with the multiarch tuples used in Debian, the freedesktop.org SDK and systemd, which seems unfortunate.
The "big idea" of the Debian multiarch tuples was that they are GNU Autotools tuples, with two changes that were necessary in order to flatten all cross-compatible tuples into a single tuple per ABI:
the vendor part of cpu-vendor-kernel[-abi] is omitted, similar to cross-compiler tool prefixes, so it's x86_64-linux-gnu rather than x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu;
the cpu part is defined to be normalized to the oldest or most generic CPU in a family of compatible ABIs, so it's i386-linux-gnu or arm-linux-gnueabi, not i686-linux-gnu or armv5tel-linux-gnueabi (in practice the only architectures affected by this seem to be the 32-bit x86 and ARM families).
If Appstream treated x86-linux-gnu as a compatibility alias for i386-linux-gnu instead of the other way round, then I think its tuples would exactly match multiarch tuples, with the possible exception of x32 (which has GNU and multiarch tuples x86_64-linux-gnux32, whereas Appstream currently only recognises the gnu_ilp32 used for the equivalent ILP32 ABI on ARM - but x32 is basically dead so this maybe isn't a big problem).
The text was updated successfully, but these errors were encountered:
Makes complete sense to me, and this divergence was probably an oversight from the start. I didn't know the freedesktop SDK also uses the same schema, that's very nice! :-)
As far as I know, the freedesktop SDK is the second independent use of Debian-style multiarch (libdir = /usr/lib/MULTIARCH), after Debian and its derivatives.
It's a sensible design for this purpose :-) Which is probably why there were no objections when I asked for feedback about adopting it for AppStream (either that, or nobody else cared that much :-P).
I'm currently traveling, so it might take a bit of time for me to actually make this change, but this issue is tagged, so I won't forget.
Looks like ia32 was the actual expected name for this... A bit of a mess, thank you for raising this, as apparently AppStream itself was confused about how to call this.
data/platforms.ymlusesx86as the preferred spelling for the shared ABI of all 32-bit x86 CPUs, andi386as a compatibility alias.This makes Appstream almost, but not quite, compatible with the multiarch tuples used in Debian, the freedesktop.org SDK and systemd, which seems unfortunate.
The "big idea" of the Debian multiarch tuples was that they are GNU Autotools tuples, with two changes that were necessary in order to flatten all cross-compatible tuples into a single tuple per ABI:
x86_64-linux-gnurather thanx86_64-pc-linux-gnuorx86_64-unknown-linux-gnu;i386-linux-gnuorarm-linux-gnueabi, noti686-linux-gnuorarmv5tel-linux-gnueabi(in practice the only architectures affected by this seem to be the 32-bit x86 and ARM families).If Appstream treated
x86-linux-gnuas a compatibility alias fori386-linux-gnuinstead of the other way round, then I think its tuples would exactly match multiarch tuples, with the possible exception of x32 (which has GNU and multiarch tuplesx86_64-linux-gnux32, whereas Appstream currently only recognises thegnu_ilp32used for the equivalent ILP32 ABI on ARM - but x32 is basically dead so this maybe isn't a big problem).The text was updated successfully, but these errors were encountered: