Arch naming convention in Github releases: x86_64 vs amd64

[Romain-Geissler-1A]

Hi,

I am looking to use nfpm in my company. When looking at the deliverables link to the latest release, I see that the tarballs don't seem to follow the same consistent naming convention:

• For x86_64: nfpm_2.41.0_Linux_x86_64.tar.gz. The arch naming convention used here is the "kernel" one: x86_64. The one also used by the rpm ecosystem (also known as amd64 in the debian ecosystem)
• For ARM: nfpm_2.41.0_Linux_arm64.tar.gz. The Arch naming convention used here is the "golang" one: arm64. The one used by the debian ecosystem (also known as aarch64 in the rpm ecosystem).

It doesn't feel super consistent to mix naming conventions. Is it done on purpose ? Is it done like this somehow to stay backward compatible because it used to be like this historically ?

Cheers,
Romain

[caarlos0]

Hey! It's mostly historical... but also, darwin still says arm64 in uname, and even so, each linux distro seems to have its own naming convention around arm64.

not sure if it's worth changing it.

[Romain-Geissler-1A]

Ok. I download/package quite some go delivrables for my company, and I had never seen such a convention mismatch so far. In the end I ended up adding an "if" in my scripts, with a big comment explaining that the convention everyone follows isn't followed for nfpm for whatever reason (it's true that we see some using are amd64, some using x86_64, but I had never seen people mixing convention inside deliveries of the very same projects in different architectures). Besides making scripting a bit weirder, it's no big deal, I can live with it. I usually use things like "deliverable-name-Linux-$(uname -m).tar.gz" when using the "kernel" convention, and "deliverable-name-Linux-$(arch-convention-converter -t go "$(uname -m)").tar.gz" for people following the "go" convention (arch-convention-converter is some simple internal tool we install to ease this convention conversion as indeed there is no consensus on the convention to use).

[caarlos0]

yeah in retrospect the best thing to be would be to use go's standard everywhere, but for historical reasons now I can't really do it.

maybe for the next major, though.