I worked on the Cloud Foundry buildpacks team for a while, so I have seen the good and the bad of the buildpacks approach. But actually using Docker in anger has made me appreciate buildpacks more than I used to. Docker is step back in <i>some</i> respects, analogous to how lower-level languages are step back in some respects from higher-level languages.<p>As for your questions:<p>1. A buildpack is meant by design to be an opinionated builder for a particular stack, not a totally pluripotent environment. If you need total control, you can have it by using Docker and sending those images to run on CF.<p>The binaries you see being pulled in are either specifically built by Heroku for Heroku or by Cloud Foundry for Cloud Foundry. They&#x27;re not random links plucked out of a Google search. It&#x27;s not as though the Debian team aren&#x27;t building binaries too.<p>2. The set of packages for Cloud Foundry in the &quot;stack&quot;[1] or rootfs is set by the buildpacks team, based on balancing the needs of various buildpacks consumers. Heroku do something similar.<p>It&#x27;s ad hoc insofar as any extremely consumed library is ad hoc.<p>The concept of buildpacks is that you, the developer, don&#x27;t have to care about what is installed. You throw code over the wall and it launches. For operators, the attraction is that there is a single known base environment and that it can be upgraded easily when CVEs are announced.<p>In theory a Docker container can be whittled down to the minimum dependencies needed to run the software, but it requires tedious and often difficult-to-understand effort, so very few people do it. And indeed the whole reason to go through that effort is to make smaller images. When you have a single reference image, that argument is largely moot.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;cloudfoundry&#x2F;stacks" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cloudfoundry&#x2F;stacks</a>