3 ms·

>I've never understood why there isn't a "meta-package manager" Because it's a fool's errand. The resulting mess would be the lowest common denominator of all

>I've never understood why there isn't a "meta-package manager" Because it's a fool's errand. The resulting mess would be the lowest common denominator of all the supported packaging tools. All of the various language-specific package managers do not touch things outside of their domain, leaving huge gaps to fill in. 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? 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 /usr directory. npm makes nested directory structures anywhere. Brew installs to /usr/local. How would you deal with the source vs. binary based package managers? Centralized vs. decentralized? How about package managers that require root privileges vs. unprivileged ones? What software bootstraps the entire system? I could go on, but I hope you can see the futility. Even if you could somehow reconcile all of these things, what did it get you? You still wouldn't know the precise dependency graph of your software because most package managers can't tell you that. You wouldn't get build reproducibility because most package managers don't address it. You wouldn't get transactional upgrade and rollback of software because most package managers do not use atomic operations. Guix can handle software written in any language, allows unprivileged package management, allows you to create isolated environments of packages (like virtualenv, bundler, etc.), deduplicates all packages system-wide via a content-addressable storage system, uses atomic operations for transactional upgrades and rollbacks, and more. A meta-package manager built on top the plethora of today's awful package management tools couldn't easily achieve any of these features.

derefr 11y ago
> 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? Because that dependency is in the meta-package's manifest. Realize that I'm talking here about an entire ecosystem of "meta-package formulae" that contain instructions to make particular tool-calls on particular systems. > 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 /usr directory. npm makes nested directory structures anywhere. Brew installs to /usr/local. How would you deal with the source vs. binary based package managers? Centralized vs. decentralized? You wouldn't reconcile any of these things, any more than things are reconciled now when you "brew install" one thing and "gem install" another and "npm install -g" a third. The result is a heterogenous multi-runtime system, but it continues to work, because each tool 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. > How about package managers that require root privileges vs. unprivileged ones? The meta-package manager could assume the existence of a self-elevating wrapper tool like Debian's wajig(1), and provide such shims for package managers that don't have one. > What software bootstraps the entire system? The regular OS package manager. --- I don't think I'm being clear here; the point wouldn't be to replace the system package manager. The point is to automate the use of all the various package-management tooling for configuration management in a unified, declarative manner. I would expect the meta-package for e.g. Postgres to look a lot like a Chef cookbook for installing Postgres, but with the limitation that—where a Chef cookbook would first attempt to use a package manager, and then "fall back to" 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. 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 already 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. If this tooling was available and baked into server VM images and so forth, you could, for example, mostly replace the "cloudinit" instance-initialization system with a simple package list; or create something like a "virtual AMI" that takes a parent AMI ID and a "[{package, version constraint}]" list, and derives a new child image to launch on a set update schedule.
- lfam 11y ago
  > 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 already 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. I think there has been a misunderstanding. Guix is a standalone OS-independent (Linux only) package manager. I am using it on Debian right now. The software installed by Debian has no knowledge of the Guix software and vice versa. GuixSD is the OS built around Guix.
  - panglott 11y ago
    Wow, it looks like GuixSD has made a lot of progress since the last time I looked into it. https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/

derefr 11y ago

> 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? Because that dependency is in the meta-package's manifest. Realize that I'm talking here about an entire ecosystem of "meta-package formulae" that contain instructions to make particular tool-calls on particular systems. > 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 /usr directory. npm makes nested directory structures anywhere. Brew installs to /usr/local. How would you deal with the source vs. binary based package managers? Centralized vs. decentralized? You wouldn't reconcile any of these things, any more than things are reconciled now when you "brew install" one thing and "gem install" another and "npm install -g" a third. The result is a heterogenous multi-runtime system, but it continues to work, because each tool 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. > How about package managers that require root privileges vs. unprivileged ones? The meta-package manager could assume the existence of a self-elevating wrapper tool like Debian's wajig(1), and provide such shims for package managers that don't have one. > What software bootstraps the entire system? The regular OS package manager. --- I don't think I'm being clear here; the point wouldn't be to replace the system package manager. The point is to automate the use of all the various package-management tooling for configuration management in a unified, declarative manner. I would expect the meta-package for e.g. Postgres to look a lot like a Chef cookbook for installing Postgres, but with the limitation that—where a Chef cookbook would first attempt to use a package manager, and then "fall back to" 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. 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 already 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. If this tooling was available and baked into server VM images and so forth, you could, for example, mostly replace the "cloudinit" instance-initialization system with a simple package list; or create something like a "virtual AMI" that takes a parent AMI ID and a "[{package, version constraint}]" list, and derives a new child image to launch on a set update schedule.

lfam 11y ago
> 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 already 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. I think there has been a misunderstanding. Guix is a standalone OS-independent (Linux only) package manager. I am using it on Debian right now. The software installed by Debian has no knowledge of the Guix software and vice versa. GuixSD is the OS built around Guix.
- panglott 11y ago
  Wow, it looks like GuixSD has made a lot of progress since the last time I looked into it. https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/