"RepoTags" in directory transport miessed

[hustcat]

RepoTags in directory transport miessed:

# skopeo inspect dir:busybox-dir  
{
    "Digest": "sha256:29f5d56d12684887bdfa50dcd29fc31eea4aaf4ad3bec43daf19026a7ce69912",
    "RepoTags": [],
    "Created": "2016-10-07T21:03:58.469866982Z",
    "DockerVersion": "1.12.1",
    "Labels": {},
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:56bec22e355981d8ba0878c6c2f23b21f422f30ab0aba188b54f1ffeff59c190"
    ]
}

[mtrmac]

RepoTags does not make any sense for dir: . It is a list of all tags in the repository (not a list of tags applicable to the image), and dir is not a tag mapping management system; the only identification of an image in dir: is the directory path.

In fact RepoTags does not really fit skopeo inspect for a docker: image either (it is a property of the repository, not of the inspected image), we are leaving it around only for backward compatibility.

What are you really trying to find out about the image?

[hustcat]

I just think busybox-dir means a repository directory, it may be contain mutiple tags

[mtrmac]

That’s not how dir: works: it doesn’t even ask for a tag anywhere, after all. Only the path identifies an image, and $dir/manifest.json is the image manifest. There is no naming system, and, no facility for storing multiple images in a single directory; uploading a new image into the same directory overwrites manifest.json, making the old image inaccessible.

dir: has really been created as a debugging/testing tool; currently it is not supposed to be a full-featured replacement for a "real” container image repository server.

[runcom]

dir: has really been created as a debugging/testing tool; currently it is not supposed to be a full-featured replacement for a "real” container image repository server.

just want to echo this. dir: is just for debugging and we do not plan to make it a full featured transport like the other (real)

[rhatdan]

Why not add ostree:PATH?

[mtrmac]

Looking at #155, it is not clear to me how the pieces are ultimately supposed to fit together for @hustcat .

ostree: might be useful for #242 though.

[mtrmac]

The core of the request, RepoTags for dir:, does not reflect how dir: actually works. Please file a separate issue if anything else (multi-image OCI index support?) is needed.