（Linuxディストリビューションでは比較的新しいバージョンです）
Redhat / CentOSに.debパッケージ（aptまたはdpkgを使用）をインストールできないのはなぜですか？それともDebian / Ubuntuの.rpmパッケージですか？
私が理解したところ、Debian / Ubuntuベースのシステムはパッケージマネージャとしてaptとdpkg（.debファイル）を使用し、RedHatベースのシステムは.rpmを使用します。しかし、これは単なる習慣/好みにすぎませんか、それとも違いはもっと深いですか？
RedHat/CentOs に .deb パッケージをインストールする方法を説明するインターネット上のすべてのページで切り替えるまず、.rpmファイルに移動します。
しかし、基本的に誰かがRedHat / CentOSにdpkgまたはaptをインストールし、それを使用して.debファイルを直接インストールすることを禁止するのは何ですか？
私の理解は.debと.rpmは本当に美しいタールボールです！デフォルトのバイナリはRedHat / CentOsとDebianで実行できるはずです。そうですか？つまり、両方のディストリビューションで同じ実行ファイルを手動で持っている場合は、両方のディストリビューションで実行する必要がありますか？ （そうでない場合は、.rpmと.debの間の非互換性を確実に理解します）
追加の質問：誰かがLinuxの世界にバイナリを展開したい場合、バイナリをサポートしてパッケージ化する必要があるシステムの数は何ですか？ （もちろん彼は好きなだけ持って行くことができますが、何を言うのか分かります）
以前は誰もこの質問をしたことがないようです。私はおそらくこれに比較的新しい基本的なものを見逃しています。
この問題に関するすべての文書も歓迎します。
ベストアンサー1
通常、同じシステム上で異なるパッケージマネージャを混在させることは禁止されていません（配布版では、外部パッケージをインストールできないようにパッケージ化された外部パッケージマネージャを変更することがよくあります）。通常、何をしているのかを知らない限り、そうしないとどうなりますか？これは非常に不快です。これがおそらく非常に悪い考えであるほとんどの理由は次のとおりです。
- パッケージマネージャは、ファイルシステムの概念を管理し、独自のデータベースでそれを追跡することを担当します。異なるパッケージマネージャを混在させることは、各パッケージマネージャが他のパッケージマネージャを知らずにパス名を追跡するので、f.exを無視することを意味します。バージョン指定された依存関係の要件とファイルが競合し、他のパッケージマネージャーのパス名を上書きして、予期しない隠しバージョンの依存関係が満たされなくなります。
- パケット形式は通常、ある程度機能的なパリティを持たなければなりませんが、依然として意味論的に大きな違いがある可能性があります。それらは単純なコンテナではありません。ファイルシステムのロード、依存関係情報、管理者スクリプトまたは設定、回復またはクリーンアップ操作を実行し、タスクを自動的にトリガーするスクリプトレットを含むパッケージメタデータも含まれます。
- さらに、ディストリビューション間の大きな違い（同じパッケージマネージャを使用している同じスイート内でも）は、戦略とオブジェクトが一緒に統合される方法（ファイルシステム登録コンテンツにアイテムが配置される場所、場所、方法など）に由来します。多くの場合、デプロイメント固有またはパッケージマネージャー固有のインターフェイス（たとえば）、デフォルトのビルドフラグ、パッケージングの粒度
dpkg-divert（アップストリームプロジェクトをデプロイメントパッケージに分割する方法と場所）、アクティブにするアップストリーム機能、アクティブ化方法、および違いの程度を使用します。 from upstream（存在する場合）が有効になります。たとえば、一部のディストリビューションにはゼロ発散ポリシーがありますが、他のディストリビューションでは、アップストリームがABIに違反している場合は共有ライブラリSONAMEを使用しますが、これに対する修正はリリースされません。 - リリースAの名前がリリースBのアップストリームプロジェクトと同じであるという保証はなく、ネームスペースはバージョンスペースではなく独立しています。普遍的に簡単に表現できない相反するネームスペース衝突アップストリームがたくさんあり、今もありました。したがって、リリース境界を越えるときは、依存関係メタデータを使用することさえ意味がないかもしれません。バージョンスペースに関しては、ディストリビューションは、異なる時点や他の理由でバージョン時代（概念がある場合）などの機能を使用するか、回避などのバージョンリカバリ
1.0really2.0トリックを使用します。不要なエポックを使う。 - 上記の点とディストリビューションの不一致に関して、一部のディストリビューションはアップストリームパッチを適用するため、プログラムや共有ライブラリ、または他のインターフェイスが他の基本的なビルドフラグのようなものは言うまでもなく、APIまたはABIと互換性があるという保証はありません。
要約すると、同じシステムでパッケージマネージャを混在させることができますか？確かならf.ex。完全に独立したファイルシステム階層を管理し、可能自分のchrootまたはf.exで作業します。管理者/およびその他/オプション。そうでない場合の最善の方法は、パッケージ形式を変換し（例で述べたようにalien）、それを使用してこれらの外部パッケージをデフォルトのパッケージシステムにインポートすることです。しかし、この方法も成功することを保証することはできません。しかし、それ以外は強く反対します。私はUbuntuパッケージをDebianシステムにインストールしないことをお勧めします（前者は後者の派生です）。なぜなら、dpkg私はUbuntuパッケージを拒否し、例えばこれに似た新しい強制オプションが必要になるからです--force-vendor。
アップストリームがこれらの多様性をどのように処理するかについての質問について私が好み、推奨するソリューションは、プロジェクトをさまざまなディストリビューションに簡単にパッケージ化できるようにアップストリームのベストプラクティスに従うことです（f.ex。https://wiki.debian.org/UpstreamGuide）次に参加するか、展開パッケージにこれらの問題を処理させます。 「汎用」と見なされるさまざまなコンテナ形式のいずれかを使用する方が良い場合を除き、もちろんすでに複数の競合形式（たとえば、、snapなどflatpak）appimageがあるため、再決定する必要があります。私の考えでは、アップストリームは通常、パッケージングを処理しないか、パッケージングに集中するためにいくつかの主流の形式を選択します（たとえば、および.deb）.rpm。