両方をネイティブにサポートするディストリビューションは存在しないと思いましたが、Bedrock Linux が開発中であることがわかりました (情報を提供してくれた iMalinowski に感謝します)。他のディストリビューションでは、 alien などの変換ツールを使用できます ある形式から別の形式に変換します。十分な時間とエネルギーがあれば、ソフトウェアベースのものは何でも実行可能であるため、そのようなディストリビューションを構築することは可能です (ただし、.deb の機能の違いを考えると)。 そして .rpm パッケージ、かなり難しい）
ただし、これはおそらく、両方のパッケージ形式をサポートすることで、どこからでもパッケージをインストールできるため、作業が簡単になるという考えから生じています (まあ、.deb を提供する場所ならどこでも) または .rpm ）。哲学的に、それには欠陥があります。ディストリビューションは一貫したパッケージのセットです。そのディストリビューション用のソフトウェアを提供したい場合は、そのパッケージ形式 (さらに重要なのはメタデータ) の使用を含め、具体的にそれをターゲットにする必要があります。複数のパッケージ形式をネイティブにサポートしても意味がありません。
(Debian の世界では、パッケージの命名法がかなり均一であり、ほとんどのディストリビューションが継承ツリーに適合するため、パッケージは主なターゲットではないバリアントでも機能します。RPM の世界ではそうではありません。マッチングは悪い考えです。)
他のディストリビューションからのものを混ぜずに、ディストリビューションのルールとエコシステムに固執して、ディストリビューションを目的のシステムを構築するためのベースと見なす必要があります。混合とマッチングをサポートする (またはクロスディストリビューション環境を提供する) には、Steam ランタイム、Flatpak などの高レベルの抽象化が必要です。
Bedrock Linux はこれを行います。私がこれをやった、またはそれが良い考えだと言っているわけではありませんが、それは行われています.
いいえ、そのようなモンスターは構築されるべきではありません。たとえば、オペレーティング システムでアプリケーションを実行するために必要なすべてのものが含まれる MacOS アプリケーション バンドルとは異なり、RPM および .deb パッケージはほとんどの場合、共有ライブラリなどの他のパッケージに依存しています。 Linux パッケージには、存在する必要がある他のパッケージがリストされており、パッケージ マネージャーはそれらの要件を適用するのに役立ちます。さらに、Linux ディストリビューションは処理方法が異なります (例:/etc/network/interfaces.d 対 /etc/sysconfig/network-scripts ).
同じパッケージ フォーマット ファミリ内の任意のリポジトリからのパッケージを混在させるべきではありません。つまり、CentOS マシンに SuSE パッケージをインストールすることは、どちらも RPM を使用しているにもかかわらず、問題を引き起こすだけです。自分が何をしているのかを正確に理解していない限り、同じ OS の別のバージョン向けのパッケージ (例:16.04 システム上の Ubuntu 14.04 パッケージ) をインストールすることさえしません。
したがって、同じシステムで RPM と .deb の両方をサポートしようとするのは論外です。特定の絶望的な状況では、 alien を使用して特定のパッケージを変換できます 、しかし、そのようなハッキングから必然的に発生する問題のトラブルシューティングに多大な努力を払うことを期待する必要があります.