&gt; How would a meta-package manager know that installing the pg Ruby gem required having the PostgreSQL shared library and header files available at build time?<p>Because that dependency is in the meta-package&#x27;s manifest. Realize that I&#x27;m talking here about an entire ecosystem of &quot;meta-package formulae&quot; that contain instructions to make particular tool-calls on particular systems.<p>&gt; What version of that library would it use? How would you reconcile where each package manager installs things? Traditional system package managers install to the global &#x2F;usr directory. npm makes nested directory structures anywhere. Brew installs to &#x2F;usr&#x2F;local. How would you deal with the source vs. binary based package managers? Centralized vs. decentralized?<p>You wouldn&#x27;t reconcile any of these things, any more than things are reconciled now when you &quot;brew install&quot; one thing and &quot;gem install&quot; another and &quot;npm install -g&quot; a third. The result is a heterogenous multi-runtime system, but it continues to work, because <i>each tool</i> knows how to manage its own ecosystem. A meta-package manager would call through to the regular package managers as its API for each ecosystem.<p>&gt; How about package managers that require root privileges vs. unprivileged ones?<p>The meta-package manager could assume the existence of a self-elevating wrapper tool like Debian&#x27;s wajig(1), and provide such shims for package managers that don&#x27;t have one.<p>&gt; What software bootstraps the entire system?<p>The regular OS package manager.<p>---<p>I don&#x27;t think I&#x27;m being clear here; the point wouldn&#x27;t be to <i>replace</i> the system package manager. The point is to <i>automate the use of</i> all the various package-management tooling <i>for configuration management</i> in a unified, declarative manner.<p>I would expect the meta-package for e.g. Postgres to look a lot like a <i>Chef cookbook</i> for installing Postgres, but with the limitation that—where a Chef cookbook would first attempt to use a package manager, and then &quot;fall back to&quot; mutating the system itself in a way no tooling on the system is tracking—a meta-package would instead just fail the installation if there was no package-manager source satisfying its constraints.<p>Guix is great, but it is its own OS with its own ecosystem. The point here would be to unify the API to package management on the ecosystems that <i>already</i> exist, such that you could interact with the package manager in ignorance of its host OS the same way you can currently interact with e.g. a Docker daemon while ignorant of its host OS.<p>If this tooling was available and baked into server VM images and so forth, you could, for example, mostly replace the &quot;cloudinit&quot; instance-initialization system with a simple package list; or create something like a &quot;virtual AMI&quot; that takes a parent AMI ID and a &quot;[{package, version constraint}]&quot; list, and derives a new child image to launch on a set update schedule.