3 ms·

I enjoyed this a great deal, but one thing that I don't see touched on in any of these package management posts is the difference between system-level and user-

by jfb 11y ago

I enjoyed this a great deal, but one thing that I don't see touched on in any of these package management posts is the difference between system-level and user-level package management. Maybe it's because I use a Macintosh, and thus have never been subject to the joys of apt/yum/pacman et al, but I've never been comfortable with the idea that I could install some binary or library and it'd be puked into the system execution context. I use homebrew, which has its problems no lie, but I can upgrade my own versions of software that might conflict with system level stuff without fear. I'd like the distribution to stick to its knitting and leave the decisions about my personal world of versioning and dependencies to me.

chriswarbo 11y ago
> Maybe it's because I use a Macintosh, and thus have never been subject to the joys of apt/yum/pacman et al, but I've never been comfortable with the idea that I could install some binary or library and it'd be puked into the system execution context. I don't use a Macintosh. Is their OS system not built out of binaries or libraries? How are those managed, if not by a package manager? I was under the impression that Apple called their package manager "the App Store". > I use homebrew, which has its problems no lie, but I can upgrade my own versions of software that might conflict with system level stuff without fear. It's true that some systems' package managers don't support separation of each user's packages from each other, or from system-wide packages. For example, I've used dpkg and rpm which don't support that. However, some package managers can handle user-specific installation (e.g. Nix can), so I don't see how using a combination (e.g. using Nix for user-specific packages, in a Debian system managed by dpkg) is any different from using homebrew alongside whatever-the-Macintosh-package-manager-is. I've found that using the same package manager for both makes life easier though; e.g. it avoids having two copies of something installed, since one PM didn't spot that the other had already installed it. > I'd like the distribution to stick to its knitting and leave the decisions about my personal world of versioning and dependencies to me. Personally, I consider myself to be in charge of my computers, so my personal decisions about versioning and dependencies apply to both user-specific packages and the whole system; e.g. if I want to test on different versions of Python, I should be able to; if I want to have my kernel built with different compiler flags, I should be able to.
- aikah 11y ago
  > I don't use a Macintosh. Is their OS system not built out of binaries or libraries? How are those managed, if not by a package manager? I was under the impression that Apple called their package manager "the App Store". App Store isn't a package manager, this is a store where end users download applications like Google Play, has a lot of restrictions regarding what can be published and distributed. One certainly cannot distribute libraries through the App Store or register alternative repositories. And the App Store doesn't resolve dependencies or stuff like that.
mook 11y ago
System-level package management is mostly an open-source-y phenomenon; it requires the maintainers of the package repository to be able to freely recompile everything from source (so that they can all use the same shared libraries). Over in Mac-land, the closest equivalent would be your OS updates (which ship the whole set of bits as a unit, and therefore not require much in terms of management). Things in the app store are apps, i.e. not libraries, and they all have to carry their dependencies with them in a larger app bundle, thereby trading disk space for much simpler package management. This is all separate from user-level package management (homebrew, nix, etc.), and project/application/source-level package management (what that article was actually talking about).

by jfb 11y ago

chriswarbo 11y ago

> Maybe it's because I use a Macintosh, and thus have never been subject to the joys of apt/yum/pacman et al, but I've never been comfortable with the idea that I could install some binary or library and it'd be puked into the system execution context. I don't use a Macintosh. Is their OS system not built out of binaries or libraries? How are those managed, if not by a package manager? I was under the impression that Apple called their package manager "the App Store". > I use homebrew, which has its problems no lie, but I can upgrade my own versions of software that might conflict with system level stuff without fear. It's true that some systems' package managers don't support separation of each user's packages from each other, or from system-wide packages. For example, I've used dpkg and rpm which don't support that. However, some package managers can handle user-specific installation (e.g. Nix can), so I don't see how using a combination (e.g. using Nix for user-specific packages, in a Debian system managed by dpkg) is any different from using homebrew alongside whatever-the-Macintosh-package-manager-is. I've found that using the same package manager for both makes life easier though; e.g. it avoids having two copies of something installed, since one PM didn't spot that the other had already installed it. > I'd like the distribution to stick to its knitting and leave the decisions about my personal world of versioning and dependencies to me. Personally, I consider myself to be in charge of my computers, so my personal decisions about versioning and dependencies apply to both user-specific packages and the whole system; e.g. if I want to test on different versions of Python, I should be able to; if I want to have my kernel built with different compiler flags, I should be able to.

aikah 11y ago
> I don't use a Macintosh. Is their OS system not built out of binaries or libraries? How are those managed, if not by a package manager? I was under the impression that Apple called their package manager "the App Store". App Store isn't a package manager, this is a store where end users download applications like Google Play, has a lot of restrictions regarding what can be published and distributed. One certainly cannot distribute libraries through the App Store or register alternative repositories. And the App Store doesn't resolve dependencies or stuff like that.

mook 11y ago

System-level package management is mostly an open-source-y phenomenon; it requires the maintainers of the package repository to be able to freely recompile everything from source (so that they can all use the same shared libraries). Over in Mac-land, the closest equivalent would be your OS updates (which ship the whole set of bits as a unit, and therefore not require much in terms of management). Things in the app store are apps, i.e. not libraries, and they all have to carry their dependencies with them in a larger app bundle, thereby trading disk space for much simpler package management. This is all separate from user-level package management (homebrew, nix, etc.), and project/application/source-level package management (what that article was actually talking about).