[PufPufPuf]

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

[lanstin]

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.

[bluebarbet]

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.

[chuckadams]

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

[bluebarbet]

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]

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.

[hoherd]

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

[cosmic_cheese]

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]

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.

[mikepurvis]

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.

[vitorsr]

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

[e12e]

Well, there was stow/xstow...

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

https://xstow.sourceforge.net/

[shevy-java]

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

[PufPufPuf]

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

[sgarman]

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]

User, as in non-root/non-admin. Pacman, paru, yay, shelly ask for root permissions.

[QuercusMax]

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]

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.