複数のパッケージマネージャを使用するとリスクはありますか?

複数のパッケージマネージャを使用するとリスクはありますか?

別のディストリビューションのパッケージマネージャインストーラを使用すると問題が発生しますか?例:Debianベースのシステムにrpmパッケージをインストールするか、Red Hatにpacmanパッケージをインストールします。

私はparrot secを使用し、rpmとsnapsパッケージマネージャをインストールしました。しかし、私はデフォルトのパッケージマネージャであるため、主にaptを使用しますが、優れたパッケージマネージャとしてaptがすべてのプログラムを扱うわけではありません。

それでは、別のディストリビューションベースのパッケージマネージャからプログラムをインストールすると問題が発生しますか?

答え1

ディストリビューションを中断する最良の方法の1つは、他のディストリビューションのパッケージをシームレスに使用することです。 Parrotaptと Debian の両方を使用できるからといって、お互いがうまく機能aptするわけではありません。ディストリビューションごとにパッケージのバージョンが異なる場合があり、Debian パッケージをインストールすると、Parrot から番号が異なる複数の依存関係を引き出すことができます。あるいは、Debian には Parrot にないパッケージが必要な場合もあれば、その逆もあります。

残念ながら、これは良い考えではありません。

答え2

Snapパッケージマネージャは個々のファイルと仮想ファイルシステムを使用するため、問題はありません。 FlatpakやAppimagesにも同様に適用されます。その場所でのみ利用可能なアプリが必要な場合です。

しかし、RPMについても言及しました。これは問題を引き起こす可能性があります。 DebianやParrotOSなどの派生製品では使用しないでください。

答え3

一般的に言えば、これを防ぐために特別な措置を講じない限り、システムはほぼ常に中断されます。すべての配布パッケージマネージャ(NPMやPIPなどの言語PMとは対照的)は、外部のほとんどのファイルシステムを100%制御できるという前提で動作するように設計されており、仮定が維持されてい/usr/localない/home場合は動作が中断されます。かなり安定しています。会った。実際には、パッケージマネージャとは別にソフトウェアを手動で構築してインストールすることも危険です(これが通常の管理者が/usr/localこれらのツールを使用する理由です)。

ただし、これが配布用にパッケージ化されていないソフトウェアを使用できないという意味ではありません。

  • Flatpak、AppImage、またはSnapパッケージがある場合、ディストリビューションがそのフォーマットの要件をサポートできる場合、ほぼ常に安全に使用できます(ほとんどの主要なディストリビューションはデフォルトでAppImageをサポートし、Flatpakおよび/またはSnapのみをサポートします)。が必要です))。
  • ソフトウェアはDockerイメージとして提供され、Dockerを提供するすべてのLinuxディストリビューションだけでなく、WindowsまたはmacOSでも利用できます。
  • 一般的なオペレーティングシステムコンテナに基づいてソフトウェア用のDockerイメージを直接作成することもできます。
  • ほとんどの通常のパッケージマネージャを使用すると、ルートファイルシステムではなくユーザー設定可能なプレフィックスにインストールできます(APTやDNFなどのユーザーターゲットツールに常に公開されるわけではありません)。これは、必要なソフトウェアを実行できるchroot環境を作成するために使用できます。
  • FOSSなら、通常はソースからディストリビューションを構築できます。/usr/localパッケージマネージャを妨げないように、そこに物を入れるように設定したことを確認してください。GNUストー、このような作業をはるかに簡単に管理できます。)

関連情報