The podman manpages are more sufficient than the docker manpages. To further illustrate considerations when adding caching to what are supposed to be reproduci

The podman manpages are more sufficient than the docker manpages. To further illustrate considerations when adding caching to what are supposed to be reproducible [development / science] workflows, GNU Make, for example, caches outputs according to their mtime. But, specifically, newer gen build systems like e.g. Blaze and Bazel do not use mtimes to cache build artifacts. Container builders like `docker build` and `podman build` archives the filesystem after each Containerfile instruction completes; as layers named as a hash of the text of the Containerfile instruction e.g. hash(`RUN sh examplescript.sh`) -> "abcdef12342" which you can run like any other container image instance: `docker run --rm -it "abcdef12342" /bin/sh -c "find /"` Caching implies additional test case parameters, debugging, and potential failure case unreproducibility: "Flush the cache, Run it again, and Compare the output" "Turn off the caching, Run it again, and Compare" "What was supposed to have cleared the cache?" "Why does it cache everything; how did the cache fill the disk?"