c8d: inconsistent presentation of ARM64 images (linux/arm64 vs linux/arm64/v8)
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 6.1k
- Forks
- 2.2k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 43
Description
Description
From https://github.com/moby/moby/issues/48604 by @thaJeztah
Description
I noticed that there's some inconsistency in presentation of arm64 platforms; one of my images was built with linux/arm64 (no variant), and it looks like we present this as-is.
docker image ls --tree
WARNING: This is an experimental feature. The output may change and shouldn't be depended on.
IMAGE ID DISK USAGE CONTENT SIZE USED
alpine:latest beefdbd8a1da 13.6MB 4.09MB
├─ linux/arm64/v8 9cee2b382fe2 13.6MB 4.09MB
├─ linux/amd64 33735bd63cf8 0B 0B
├─ linux/arm/v6 50f635c8b04d 0B 0B
├─ linux/arm/v7 f2f82d424957 0B 0B
├─ linux/386 b3e87f642f5c 0B 0B
├─ linux/ppc64le c7a6800e3dc5 0B 0B
├─ linux/riscv64 80cde017a105 0B 0B
└─ linux/s390x 2b5b26e09ca2 0B 0B
thajeztah/ddshell:latest e332ae952d63 23.8MB 7.88MB ✔
├─ linux/arm64 1b9c0c672878 23.8MB 7.88MB ✔
└─ linux/amd64 65b8d31def37 0B 0B
AFAIK, linux/arm64 is always equivalent to linux/arm64/v8
docker pull --platform=linux/arm64 thajeztah/ddshell:latest
latest: Pulling from thajeztah/ddshell
8f5adf85e8b9: Download complete
9b3977197b4f: Download complete
414aa140181c: Download complete
b8a650d25df2: Download complete
Digest: sha256:e332ae952d6326b017e64cbb66f2514906e8d9cad56dc5d554e7cd6474f1cd45
Status: Downloaded newer image for thajeztah/ddshell:latest
docker.io/thajeztah/ddshell:latest
docker pull --platform=linux/arm64/v8 thajeztah/ddshell:latest
latest: Pulling from thajeztah/ddshell
Digest: sha256:e332ae952d6326b017e64cbb66f2514906e8d9cad56dc5d554e7cd6474f1cd45
Status: Image is up to date for thajeztah/ddshell:latest
docker.io/thajeztah/ddshell:latest
I wonder if
- we should present it in its canonical / fully-qualified format, or if we should continue presenting as-is
- ❓ would there ever be ambiguity once a
v9becomes available (and in that case, wouldlinux/arm64be equal tolinux/arm64/v9?) - ❓ if we do want to present in canonical form, should we consider that presentation (i.e., handle this on the CLI side), or should this be done on the API side (API doing normalizing)?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the docker image ls --tree entry point and trace how platform names are selected for display. The issue names no files or tests and leaves canonicalization, API behavior, and future ARM64 variants unresolved; a decision on the desired representation would be needed before implementation and validation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100