I think you're missing the GP's point. What docker provides is a way to shrink-wrap a given build and all of its runtime dependencies. Despite popular misconc

I think you're missing the GP's point. What docker provides is a way to shrink-wrap a given build and all of its runtime dependencies. Despite popular misconception, what docker does not give you is a deterministic way to build that software. A Dockerfile provides the RUN steps necessary to build the software, but dependencies must still be fetched over the network, introducing non-determinism. You can spend 6 months happily using the latest release of some image, only to find that there's a critical bug or vulnerability that needs addressing ASAP. It kind of sucks for that complacency to turn to terror when you try to patch the software and rebuild, only to find inscrutable errors due to an absolutely bonkers build system. "ERR: Version A of Foo is incompatible with version B of Bar" Okay... but what happened here? What versions were we pulling before? Oh, the precise version isn't pinned in the build system, so.. I dunno. Great. It would really help if I knew if it was A that updated breaking B, or the reverse. Then multiply that by 1000x. And then add in (for Debian-esque base images) Apt repositories disappearing over time, git feature branches being deleted, tarballs falling off the edge of the internet, etc. Now, before someone says "well, that's on you if your Dockerfile obscures so much build non-determinism!" I agree with that statement! But that is a non sequitur with respect to the original premise: the build systems (and the web of dependencies they pull in) in third-party software you don't have ownership of is getting crazier and crazier, and Docker helps perpetuate this state of affairs, and the industry suffers as a whole.