主流 Linux 发行版（deb/apt、yum/dnf、pacman 等）的默认包管理器默认进行全局安装并需要 root。以用户或组身份安装并且不需要 root 似乎更好，因为以 root 身份运行的不受信任代码会更少（如 Nix、Guix、Cargo、Pip、Gem、Cabal、Stack、CPAN）。
为了节省共享系统上的空间，可以将软件包安装到用户可读但管理员可写的目录中，但这不必是 root，并且它仍然应该允许用户安装自己的软件包。
修改受保护文件（例如 Grub）或提供服务的软件包需要修改根系统，但其他一切都应该可以从用户端完成。
这个问题说软件包可能假设它们安装到文件系统层次结构中的特定位置，但我认为这可以通过设置$PATH、$LD_LIBRARY_PATH和朋友来解决。否则，为什么不直接有一个在 chroot 中运行程序的包装器呢？
答案1
你说的是系统包管理器，它安装系统库和共享程序（也可能是守护进程），因此它们需要 root 权限。
有一些用户空间包管理器，例如 flatpack，但是如果你看一下它们，你可能会发现一些问题：
你必须学习两个（或更多）包管理器，你可能会混淆一些程序来自哪里（系统还是用户？）
依赖关系更加复杂：某个级别的包管理器无法看到其他包管理器的依赖关系。例如，如果我升级操作系统的版本，这可能会破坏某些用户，并且我无法检查用户安装的所有程序。但也恰恰相反：我的用户空间包管理器无法影响系统包。如果它需要某个包的特定版本，那么您就需要它，否则您就会迷失。因此，大多数此类用户空间包往往包含需要的依赖项（和库）。
这使得处理一个系统变得更加困难（如果你找到一种方法来整合两者）。
注意：计算机语言（带有虚拟环境的Python、带有node.js的javascript以及许多其他语言）可能有自己的系统（类似于包管理器）来处理库和其他程序。
简而言之：这很困难，现在我们通常更喜欢 docker：系统和我的容器之间有明显的分离（以及简单的边界：文件系统、网络）。现在可能我们有更多的支持（影子文件系统，独立的命名空间等）来允许用户包很好地集成在系统上，但它并没有真正解决系统易于维护的问题，用户可能会运行危险（旧的易受攻击的程序）。我觉得现在可能是可行的，但是没有太多的需求（或者志愿者）去做。
PS：你真的可以搞砸其他用户，通过安装新版本的库，或者通过安装一些程序，如sl，，les等等（所以常见命令的拼写错误）：你可以轻松地获得此类用户的所有权力。