At the very least, Linux package managers should have some concept of different layers of packages.

For example, there might be layers for “system” (core components), “environment” (display manager, DE, etc), and “user”, each of which are maintained fully separately so they can’t ever step on each others’ toes and break things. Yes, it means there will be some redundancy but for all the trouble and complexity it’s saving I think it’s a worthwhile tradeoff.

I love brew but it was decades of tradition to download source and compile as non-root on shared Unix systems. Not only were the sysadmins skilled at saying no, they were not always available at 2 am, but installing some random code, after editing the Makefile to reflect some oddity of something, was 24x7. And then when we got better offers than shared dial up hosting, it was root or nothing.

To be sure it is ridiculous, but it is also traditional.

One of the frustrating limits historically with some of these is that when you're already an unprivileged user it's been difficult or impossible to get to a sandboxed environment to perform hermetic or untrusted builds. So like with nix for example you could do a user install and then builds would build as your user, but if you installed as root, then builds would delegate out properly to nixbld users.

This has gotten better in recent years with user namespaces but it takes time for it to be adopted and achieve parity with what used to be just jumping to a user who can only write to a newly created dir in tmp.

In Debian-Ubuntu it's become a standard pattern to use `curl` or `wget` to add a third-party `deb` repo with keychain integration, because for whatever reason there's still no `apt` command for this obvious scenario. Really grinds my gears.

  echo "deb [signed-by=/etc/apt/keyrings/packages.mozilla.org.asc] https://packages.mozilla.org/apt mozilla main" | sudo tee -a /etc/apt/sources.list.d/mozilla.list > /dev/null

  # 1. Install our official public software signing key:
  wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg; cat signal-desktop-keyring.gpg | sudo tee /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
  
  # 2. Add our repository to your list of repositories:
  wget -O signal-desktop.sources https://updates.signal.org/static/desktop/apt/signal-desktop.sources; cat signal-desktop.sources | sudo tee /etc/apt/sources.list.d/signal-desktop.sources > /dev/null
  
  # 3. Update your package database and install Signal:
  sudo apt update && sudo apt install signal-desktop

There is also the possibility of using Toolbx (formerly [Fedora] Toolbox), distrobox or a container, and the underlying container's package manager. The issue then ends up being about how ergonomic it is to manage a separate guest system (and have to drop into it anytime we wish to use a binary that is unavailable in the host).

Well, there was stow/xstow...

https://www.gnu.org/software/stow/

https://xstow.sourceforge.net/

I'm a total noob in this space but I'm using pacman, paru, yay, shelly. Are those different than "userspace package manager" or are these not relevant because it's Arch?

I looked around and found this fun project -- basically "Arch Linux in userspace on top of any other Linux": https://github.com/fsquillace/junest

I haven't looked much into snap but it seems very heavyweight from the few things I've tried, which downloaded what looked like an entire OS and filled up my disk and RAM. And the fact that you run `snapd` to install a package is just... odd.

PufPufPuf wrote:

> The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago.

Each one uses their own package manager right?

What I hate is that e. g. debian puts me to conform to their FHS. I want things installed into versioned AppDirs. GoboLinux allows that; NixOS to some extent too (though they used hashed directory names). Debian does not allow me to do that. I don't want to conform to what others wrote; I want software that adjusts to my wants.

> Flatpak is more oriented towards GUI apps

Have they not recently added a mandatory systemd dependency? I can't use software that things it must force software I don't need or use onto me.