This is picking up on #246 which provided a hacky solution to prevent unnecessary download of image layers via git-annex (when they were already present in a local daemon).
I think a different approach would also solve this, and in addition address another duplication issue. With the increasing availability of Forgejo (which comes with an OCI registry) it become attractive to have a single place to store image layers. It would seem sensible to place them into the OCI registry, yet still enable retrieval via git-annex.
A dedicated special remote could use docker/podman to retrieve a particular image (identified via a tag), and extract layers.
❯ podman pull docker.io/library/python:3.11-slim-bookworm
❯ podman save --format oci-archive docker.io/library/python:3.11-slim-bookworm | tar -Oxvf - blobs/sha256/30891250f88ca9e6c5ea6a65ad86c1eded6dfb8888fac83693f173b6941db2a8 | sha256sum
blobs/sha256/30891250f88ca9e6c5ea6a65ad86c1eded6dfb8888fac83693f173b6941db2a8
More reliable/robust could be the pull via digest:
podman pull docker.io/library/python@sha256:11a132d4ac3854ecbf0e443fb552334fd37373f4b6148e646a07435c4ee111a0
This avoid breakage when a tag is "moved".
This is picking up on #246 which provided a hacky solution to prevent unnecessary download of image layers via git-annex (when they were already present in a local daemon).
I think a different approach would also solve this, and in addition address another duplication issue. With the increasing availability of Forgejo (which comes with an OCI registry) it become attractive to have a single place to store image layers. It would seem sensible to place them into the OCI registry, yet still enable retrieval via git-annex.
A dedicated special remote could use docker/podman to retrieve a particular image (identified via a tag), and extract layers.
More reliable/robust could be the pull via digest:
This avoid breakage when a tag is "moved".