Closed tnk4on closed 3 days ago
The c/image source code is hard coded to OCI Image and there is no logic to determine Docker V2S2. https://github.com/containers/image/blob/a6fbeaa1800f1081033a28771626e48d9042a99d/tarball/tarball_src.go#L85-L103
Thanks for reaching out. tarball
is an internal implementation mechanism of some features, and basically completely impossible to use from the command line.
To consume files created by podman save
, use a specific transport relevant to the image format, in this case docker-archive:
or oci-archive:
Also consider restructuring your workflow to use a registry, it’s almost certainly going to be more efficient than using tarballs because it allows sharing layer data across images and repositories, and it does not require creating temporary files to consume compressed data.
My goal is to easily know the format of archives saved by podman save
or docker save
.
I need to run two commands skopeo inspect oci-archive:
and skopeo inspect docker-archive:
for archives of unknown format.
What about the idea of adding the ability to fall back to the proper format?
That’s fundamentally ambiguous — a tarball can be purposely built to be valid in several formats simultaneously, and to contain a different image in each. Autodetection would increase user risk if consuming third-party tarballs.
I think it would make more sense to follow what Docker does (as in https://github.com/containers/podman/issues/21347 ), and to intentionally generate such ambiguous OCI-compatible archives with --format=docker
. Then users of skopeo inspect
could always, consistently use oci-archive:
and wouldn’t need to worry about auto detection.
I understand about the ambiguity of tarballs. thank you !
So how about adding the information to the output of the tarball transport?
e.g. “The MIMEType output may differ from the actual format. Please use oci-archive:
or docker-archive:
transport instead.”
The tarball:
transport is completely out of the picture. It’s just not its purpose at all to consume podman save
.
Just like I did, people who are not familiar with using skopeo might expect the tool to be perfect. It would be helpful to supplement this with documentation.
That’s very true. How did you find the tarball:
transport at all? It is explicitly missing from containers-transports(5), and I can’t see it being documented anywhere, other than a brief mention in containers-policy.json(5).
If it is documented somewhere else, we should fix that.
I found it in bash-completion while testing the command and tried it. I have not looked for any other documentation other than that.
Thanks, #2339 will filter it out.
A friendly reminder that this issue had no activity for 30 days.
If I run
skopeo inspect tarball:
on a Docker V 2, Schema 2 (docker-archive) image saved withpodman save
ordocker save
, the response is an OCI Image.Is it possible to fix it to respond with Docker V2S2?