The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago. It's ridiculous that the usual situation for non-root users is "you can't install XY but feel free to build from source". Homebrew, Mise and Nix are filling that hole now. (Flatpak is more oriented towards GUI apps, and Snap... exists.)

▲ bluebarbet 4 hours ago | parent | next [-]

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.

▲ hoherd 2 hours ago | parent | next [-]

That is not a "userspace package manager" though. That still requires root.

▲ chuckadams 3 hours ago | parent | prev [-]

Doesn't apt-add-repository do all that?

▲ bluebarbet 2 hours ago | parent [-]

For whatever reason, nobody seems to use it. It must be a good reason or else they would. [PS: It's because it doesn't add the signing keys and maybe also because it's too associated with Ubuntu.] This, for example, is the official way to add Mozilla's repo:

  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

And here's Signal's instructions:

  # 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

Bonkers.

	▲	thewebguyd 2 hours ago \| parent [-]
		I believe apt-add-repository started out as Ubuntu specific for their PPA system, didn't it? It's part of the software-properties-common package. When using it without a PPA (just giving in the repo URL) it won't add the key by default, so you have to follow it up with the wget -qO- https:/mykey.asc \| sudo apt-key add - (<< don't to this, apt-key add will add the key to the global trust) early days apt-add-repository also didn't support signed-by for the signing keys. Very early on when you added some PPA, it'd add the repo's GPG key to the global keyring, so you were better off not using it anyway.

▲ cosmic_cheese 4 hours ago | parent | prev | next [-]

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.

	▲	chuckadams 3 hours ago \| parent [-]
		Most "immutable" distro flavors do something like this. Back when I ran Aurora, it was rpm-ostree for the core system packages and homebrew in a devbox container for the rest. One incentive for maintaining the layer separation was that rpm-ostree was slow. I've since moved my desktop box to NixOS, where everything is just flakes, but my mac runs circles around it so it's just there for Steam nowadays.

▲ vitorsr an hour ago | parent | prev | next [-]

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).

▲ mikepurvis 4 hours ago | parent | prev | next [-]

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.

▲ PufPufPuf 2 hours ago | parent | prev | next [-]

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

▲ e12e 4 hours ago | parent | prev | next [-]

Well, there was stow/xstow...

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

https://xstow.sourceforge.net/

	▲	shevy-java 4 hours ago \| parent [-]
		Stow only symlinks. That's even one layer below GoboLinux, and GoboLinux is not extremely active either (it is not dead, but kind of semi-dormant, that is sometimes a few changes and improvements are added, then it goes back to hibernation again).

▲ sgarman 2 hours ago | parent | prev | next [-]

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?

	▲	hopw_roewur_ne 2 hours ago \| parent [-]
		User, as in non-root/non-admin. Pacman, paru, yay, shelly ask for root permissions.

▲ QuercusMax 4 hours ago | parent | prev | next [-]

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.

▲ shevy-java 4 hours ago | parent | prev [-]

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.