主流のLinuxディストリビューション（deb / apt、yum / dnf、pacmanなど）のデフォルトのパッケージマネージャはデフォルトでグローバルにインストールされ、ルートが必要です。ユーザーまたはグループとしてインストールし、rootが不要な場合は、rootとして実行される信頼できないコード（Nix、Guix、Cargo、Pip、Gem、Cabal、Stack、CPANなど）が減るため、より良いようです。
共有システムのスペースを節約するために、ユーザーは読み取ることができ、管理者は書き込み可能なディレクトリにパッケージをインストールできます。ただし、ルートである必要はなく、ユーザーが自分のパッケージをインストールできる必要があります。
保護されたファイル（Grubなど）または提供パッケージを変更するには、ルートシステムを変更する必要がありますが、他のすべての操作はユーザー側で行う必要があります。
この問題パッケージはファイルシステム階層の特定の場所にインストールされていると想定できますが、これは設定と友達を介して解決できると思い$PATHます$LD_LIBRARY_PATH。それ以外の場合は、chrootでプログラムを実行するラッパーを持つのはどうでしょうか？
ベストアンサー1
あなたは正しいです。システムパッケージマネージャ、システムライブラリと共有プログラム（およびデーモンも可能）をインストールするため、root権限が必要です。
いくつかありますユーザースペースパッケージマネージャたとえば、flatpackですが、見てみると、次のようないくつかの問題が見つかります。
2つ（またはそれ以上）のパッケージマネージャを学ぶ必要があり、いくつかのプログラムがどこから来たのか（システムまたはユーザー？）混乱する可能性があります。
依存関係はより複雑です。特定のレベルのパッケージマネージャは、他のパッケージマネージャの依存関係を表示できません。たとえば、オペレーティングシステムのバージョンをアップグレードすると、一部のユーザーが機能しなくなり、ユーザーがインストールしたすべてのプログラムを確認できなくなります。しかし、その逆でもあります。私のユーザースペースパッケージマネージャはシステムパッケージに影響を与えることはできません。特定のバージョンのパッケージが必要な場合はそのパッケージが必要になり、そうでなければ迷子になります。したがって、ほとんどのこれらのユーザースペースパッケージには、必要な依存関係（およびライブラリ）が含まれる傾向があります。
これにより、1つのシステムを扱うことがはるかに困難になります（両方のシステムを統合する方法を探している場合）。
注：コンピュータ言語（仮想環境を含むPython、node.jsを含むJavaScriptなど）には、ライブラリや他のプログラムを処理するための独自のシステム（パッケージマネージャに似ています）があります。
簡単に言えば、難しいです。最近、私たちは通常ドッカーを好みます。システムとコンテナ（そして単純な境界：ファイルシステム、ネットワーク）は明確に区別されています。これで、ユーザーパッケージがシステムにうまく統合できるように、より多くのサポート（シャドウファイルシステム、独立した名前空間など）があるようになりましたが、システムのメンテナンスが容易であるという問題は実際には解決されず、ユーザーが危険にさらされる可能性があります。 （脆弱なプログラムのうち古いもの）。今は可能かもしれないと思いますが、そうする必要性（またはボランティア）はあまりありません。
slPS：新しいバージョンのライブラリをインストールしたり、などのいくつかのプログラムをインストールすると（通常のコマンドのスペルが間違っている場合）、他のユーザーを混乱させる可能性があります。lesこれらのユーザーのすべての権限を簡単に取得できます。