new warning message about mismatching expected and actual platform doesn't "canonicalize" the input before comparison (ie aarch64 vs arm64)

[Romain-Geissler-1A]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

The new warning message about mismatching expected and actual platform doesn't "canonicalize" the input before comparison (ie aarch64 vs arm64).

Steps to reproduce the issue:

[root@5c9771d2427c /]# podman pull --arch aarch64 fedora
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob e0878b843331 done
Copying config 5beb352982 done
Writing manifest to image destination
Storing signatures
WARNING: image platform (linux/arm64) does not match the expected platform (linux/aarch64)  <--- unexpected warning here
5beb352982d939db3b957c8fd16da9d24bbd69f1d796169c5ddb649b3a03cf91

Describe the results you received:

We have this warning:

WARNING: image platform (linux/arm64) does not match the expected platform (linux/aarch64)

Describe the results you expected:

No warning should be printed in this case (as normally "linux/aarch64" shall be "canonicalized" to "linux/arm64" before comparison, like Docker does).

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

[root@5c9771d2427c /]# podman version
Client:       Podman Engine
Version:      4.2.0-dev
API Version:  4.2.0-dev
Go Version:   go1.18.3
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64```

[mheon]

@vrothberg PTAL

[vrothberg]

Thanks for reaching out, @Romain-Geissler-1A!

It's unfortunate that aarch64 seems to be used in the wild as it's not an official GOARCH value (see https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63) and is not really covered by the OCI image spec. But conventions matter, so I am going to take a look.

[Romain-Geissler-1A]

This lack of single convention is wider than just OCI images, for example it also creates issues for people packaging .deb and .rpm for their software where one uses one convention and the other one uses the other convention.

On the OCI side, IMO it's very important that container engine understand/accept $(uname -m) output, we use it in many places on our side to build multi-arch images. Shall there be some simple coreutils tools allowing to convert to the other naming convention, we would use it, but I don't think it exists and I don't want to write in every single of my scripts if ($(uname) -m == "x86_64") then OCIArch = "amd64" else if ....

[vrothberg]

Thanks for elaborating, @Romain-Geissler-1A! I agree, the uname issue is probably why it's being tolerated in the wild. I already have a local fix and will push it once #14654 is merged.