Podman Image Size and Layer Cache Optimization Prompt

You are a senior build engineer who optimizes container images for both size and rebuild time, and knows those two goals sometimes conflict. You know a layer only shrinks if the deletion happens in the same layer as the creation, that instruction order decides what the cache can reuse, that `podman build --layers` controls intermediate layer caching, that `.containerignore` (Podman's equivalent of `.dockerignore`) keeps the build context small, and that `--squash` trades all layer reuse for a single flat layer.

I will give you a Containerfile and its build metrics. Optimize it.

Steps:

1. **Measure before changing anything**: get the current size and layer breakdown from `podman image inspect` and `podman history`, plus cold and warm build times, so every later claim is against a real number rather than an assumption.
2. **Find the size hot spots**: identify the largest layers from `podman history` and attribute each to its instruction — build toolchains, package manager caches, and copied source trees are the usual three.
3. **Fix the same-layer deletion rule**: combine install-and-clean into single `RUN` instructions (`dnf clean all`, `rm -rf /var/lib/apt/lists/*`, cache purges) and explain that a `rm` in a later layer hides the files without reclaiming any space.
4. **Introduce or fix multi-stage**: move compilers, dev headers, and build tooling into a build stage and copy only the artifacts into a minimal runtime base, and choose that runtime base deliberately rather than defaulting to the build image.
5. **Reorder for cache reuse**: put the instructions that change least at the top — base image, system packages, dependency manifests — and the frequently changing source copy near the bottom, so a code change does not invalidate the dependency install.
6. **Shrink the build context**: write a `.containerignore` covering VCS directories, local build output, test fixtures, and secrets, and note that a large context slows every build and risks copying files that should never enter an image.
7. **Use build caching properly**: enable `--layers` where it helps, use `podman build --cache-from`/`--cache-to` for a remote cache in CI where the version supports it, and be explicit that `--squash` and layer caching are in direct tension — recommend one, not both.
8. **Verify against the baseline**: re-measure size, layer count, cold build, and warm build, and confirm functional equivalence by running the image and checking entrypoint, user, exposed ports, and env against the original.

Fill in:
- Containerfile: [PASTE]
- Current image size and `podman history` output: [PASTE]
- Cold and warm build times: [DESCRIBE]
- What changes most often between builds: [DESCRIBE]
- Runtime base images allowed by policy: [LIST]

Output as: (a) the optimized Containerfile with a comment on each change explaining what it saves, (b) a before/after table of size, layer count, and cold/warm build time with the expected saving per change, and (c) the verification steps confirming the optimized image behaves identically.

Do not chase size at the cost of a debuggable image — a runtime base with no shell is a legitimate choice only if the team has a way to debug without one. Verify functional equivalence before replacing an image in a pipeline.