Hacker News Reader

Comment by devit | Hacker News Reader

It might be time to switch to a package management paradigm that doesn't require SAT solvers.

For example, one in which packages do not conflict because they are installed in a directory for each package, and there is an "alternatives" mechanism for any global choice.

View on HN

Daniel J. Bernstein, around the turn of the century, proposed a /package hierarchy (for package management without the need for conflict resolution) and a /command directory.

* http://cr.yp.to/slashpackage.html

* http://cr.yp.to/slashcommand.html

Their major problem was the idea that one had to register things with what was to most of the world just some bloke on another continent. But they had concepts like a hierarchical package naming scheme ("admin/", "mail/", &c.), self-contained build trees with versioned names, symbolic links to denote "currently selected version", and an "index"/"alternatives" directory full of symbolic links.

The /package directory sounds sort-of like what GNU Guix and Nix do. They have a "store" directory (say, /gnu/store) that works like a content-addressable storage system. All store entries are associated with a SHA256 hash that uniquely identifies the build. There's no SAT solver needed because package recipes precisely describe their dependencies, all the way down to the bootstrap binaries for the system. There's also no global /usr that prevents multiple versions of the same software from existing on the same machine in a sane way. Users can manage their own "profiles" which are symlink forests to a set of store items. Each user can choose their own set of software without needing root privileges to install it and without fear of breaking another user's environment. Furthermore, users can manage arbitrarily many profiles and even create temporary environments (perhaps in a Linux container if you're into that) to perform one-off tasks or hack on a new project without polluting any profiles. You also get transactional package upgrade/rollback.

I'm one of the Guix hackers, and we're about to make a new release announcement today, so I encourage you to check it out: http://gnu.org/software/guix

it would be interesting if you could talk about Nix, Guix and the 800-lb gorilla: click packages. incidentally, they just made an announcement: https://news.ycombinator.com/item?id=10506188

I have been saying that we need a new package system like this and a new file structure. The need for terse folder names has been over for close to 40 years.

You find some of that in Gobolinux.

What and have the dependencies for each package in the package directory node_modules style? No thanks, at least not unless it is on a file system that deals with duplicate subtrees within the filesystem.

Just support installing multiple library versions "side-by-side".

I prefer to just have the zlib-version without known buffer overflows, thank you. That will generally mean fixes are backported to a frozen api that is known to work wit a subset of packages (say 10.000 or so). No changes (except less undocumented behaviour/crashes) on security patching.

Feature changes are ok on release upgrades.

Indeed. http://nixos.org/nix/

And also: http://www.gobolinux.org/

Reply on news.ycombinator.com