Fixed Debian platform tag for aarch64/arm64

[kamermans]

This PR fixes 64-bit ARM builds on Debian and its derivatives. Debian uses arm64 to describe its architecture whereas the kernel (even on a Debian machine) used the term aarch64.

This problem does not affect RPM-based distros or ArchLinux/pacman from what I can tell, although it does appear that FreeBSD uses arm64, so I've added a check there for the bit length. It looks like there is only x86 support in the code for FreeBSD though, so more might need to be done to support ARM on that platform.

I've also added a couple tests in-line with the amd64 vs x86_64 tests.

I haven't tested this yet, but the changes seem quite trivial to me.

EDIT: Also, I see there is no support for native Apple M1 binaries. These are also 64-bit ARM, and I don't recall the architecture name for them (it's arm64 in Golang).

[jordansissel]

Nice work. Thank you :)

[kamermans]

No problem, happy to help!

[LINKIWI]

This commit introduces a regression for packaging systems that expect aarch64 as the architecture identifier, like Termux.

Can this "smart" auto-correction behavior be parameterized or otherwise made opt-in by default?

It's not really clear to me why there needs to exist special-case logic for the aarch64 string, which is not recognized as a valid Debian architecture identifier in most Linux distributions. If someone specifies aarch64 explicitly on the command line, I'd expect this to be reflected as-is in the Debian package metadata, and not silently changed by fpm to something else.

[jordansissel]

It's not really clear to me why there needs to exist special-case logic for the aarch64 string

The short version is this: On Debian systems where the kernel reports aarch64 for the hardware platform uname -m, Debian calls this "arm64" instead of "aarch64".

Example, running Debian on my m2 macbook via docker:

root@903d0a0c563c:/# uname -m
aarch64
root@903d0a0c563c:/# dpkg --print-architecture
arm64

This isn't the first time a package distributor uses a different name for a hardware platform than other projects (like the kernel, compilers, etc). For example, Red Hat calls "x86_64" what Debian calls "amd64".

Looking at Termux's packages, it seems like this distro uses Debian's packaging formats, but otherwise seems to deviate from Debian and its derivatives.

Example, OpenBSD netcat:

• Termux: https://packages.termux.dev/apt/termux-main/pool/main/n/netcat-openbsd/netcat-openbsd_1.219-1-0_aarch64.deb
• Debian: http://ftp.us.debian.org/debian/pool/main/n/netcat-openbsd/netcat-openbsd_1.219-1_arm64.deb

Termux uses 'aarch64' where Debian uses 'arm64'. Ubuntu (a Debian derivative) also uses 'arm64'

If someone specifies aarch64 explicitly on the command line, I'd expect this to be reflected as-is in the Debian package metadata, and not silently changed by fpm to something else.

This is a good point. In other areas of fpm, attempted-corrections like this are logged. Example, Example 2.

I'm open to having fpm log a message about this architecture naming conversion.

Can this "smart" auto-correction behavior be parameterized or otherwise made opt-in by default?

It feels like the right solution might be to add support specifically for Termux, such that any conversions can target Termux specifically. For example, if converting a Debian package to Termux, fpm /should/ replace "arm64" (Debian's term) with "aarch64" (Termux's term).

Where are you building packages for Termux? On an existing Termux system? Or on another system/os ?

[jordansissel]

@LINKIWI I think we can improve fpm for cases such as Termux. If you have time, please file a new issue to focus discussion on things specific to Termux.

[LINKIWI]

Hi, thanks for the consideration. We have deprecated fpm and migrated to another packaging solution, since this isn't the first time a minor or patch version upgrade has introduced a critical regression.