Open cgwalters opened 5 months ago
Also, while it may not be a problem in practice in this specific instance, any time we're synthesizing commands to be interpreted by a shell script, it's a best practice to shell quote.
Will add dnf clean all.
If it proves not to be a Containerfile approach like this it's fine, just playing around to see what's possible.
It's kinda nice to have a recognizable Containerfile to inspect and manually edit if wanted.
I was able to prevent the duplicate dnf download by ensuring cache gets copied into the Container via:
actions.append("COPY cache/dnf /var/cache/dnf")
this fixed some caching problems as we only rely on the cache in the host /var and just copy it in to the Container when required.
But... Since you brought it up, gonna try and do the copy, dnf install and dnf clean all in one layer to minimize things...
I drastically changed things after these comments, now we always append to a squashed container image, removing the old one, saving lots of space, also clean up dnf cache etc.
The other thing about using a Containerfile approach is it will encourage figuring out every little nook and cranny of the Containerfile build process, replacing a kernel, etc. By consolidating on one approach wherever possible.
We kinda lose the capability to upgrade though with this approach, maybe I should add a second Containerfile for archiving purposes that keeps all the commands logged for Fedora 41 -> 42 type upgrades
There's now two Containerfiles:
/var/Containefile /var/Containefile-unsquashed
the first one represents what we actually use, the second one is for if we want to "podman build" everything from scratch again.
Thanks for starting this. I looked at the code:
dnf clean all
so we're pointlessly duplicating the (compressed) RPMs in the final image.Of course, this leads into a larger problem domain of actually how we precisely and reliably cache that content, which leads into basically needing a non-Containerfile buildsystem.