3 ms·
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 a
by devit 11y ago
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.
- tyho 11y agoWhat 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.
- devit 11y agoJust support installing multiple library versions "side-by-side".
- e12e 11y agoI 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.
- JdeBP 11y agoDaniel 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/slashpackage.html * http://cr.yp.to/slashcommand.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.
- baldfat 11y agoI 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.
- davexunit 11y agoThe /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 http://gnu.org/software/guix
- sandGorgon 11y agoit 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 https://news.ycombinator.com/item?id=10506188
- digi_owl 11y agoYou find some of that in Gobolinux.
- david_ar 11y agoIndeed. http://nixos.org/nix/ http://nixos.org/nix/
- norswap 11y agoAnd also: http://www.gobolinux.org/ http://www.gobolinux.org/