RPMと.debパッケージの両方をサポートするLinuxディストリビューションをビルドすることは可能ですか？
理論的には、rpmパッケージとdebianパッケージの両方をサポートできるLinuxディストリビューションを構築することが可能かどうか疑問に思っています。
両方をサポートするディストリビューションはどこにありますか？
そしてそれができない場合でも可能ですか？
Bedrock Linuxがこれを行います。 私がこれを実行した、またはそれが良いアイデアであるとは言わないが、実行されている。
両方をネイティブでサポートするディストリビューションは存在しないと思いましたが、それは 判明 開発中のものがあります Bedrock Linux （ありがとう iMalinowski 情報）。他のディストリビューションでは、 alien などの変換ツールを使用して、1つの形式から別の形式に変換できます。十分な時間とエネルギーが与えられれば、ソフトウェアベースのものが何でも実行できるため、そのようなディストリビューションを構築することは可能です（ただし、.debパッケージと.rpmパッケージの機能の違いを考えると、かなり困難です）。
ただし、これらはすべて、両方のパッケージ形式をサポートすると、どこからでも（つまり、.debまたは.rpmを提供する場所から）パッケージをインストールできるため、作業が簡単になるという考えに由来します。哲学的には、それは欠点です。ディストリビューションは一貫したパッケージのセットです。その配布用のソフトウェアを提供する場合は、パッケージ形式（さらに重要なことにはメタデータ）の使用を含む、具体的にそれを対象とする必要があります。複数のパッケージ形式をネイティブでサポートしても意味がありません。
（Debianの世界では、パッケージの命名法がかなり同種であり、ほとんどのディストリビューションが継承ツリーに適合するため、パッケージは主なターゲットではないバリアントで機能します。RPMの世界ではそうではありません。両方のケースで、マッチングは悪い考えです。）
ディストリビューションは、他のディストリビューションからのものを混ぜることなく、ディストリビューションのルールとエコシステムに忠実に、希望のシステムを構築するためのベースとして考える必要があります。混合とマッチングをサポートするには（または、クロスディストリビューション環境を提供するには）、Steamランタイム、Flatpakなどの高レベルの抽象化が必要です。
いいえ、そのようなモンスターは作るべきではありません。たとえば、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を使用して特定のパッケージを変換することができますが、そのようなハックから必然的に発生する問題のトラブルシューティングには多くの労力を費やすことを期待する必要があります。
はい、それは可能ですが、それは配布を台無しにします。
パッケージは単なる形式ではなく、ある形式から別の形式に簡単に移植できます。
注：すべてのパッケージ、バージョン、依存関係、構成ファイル、インストール前後のスクリプトの一覧を一元化したいので、パッケージインストールツールを移植する必要があります（あるパッケージを別のパッケージで置き換える場合、別のパッケージで）形式、アンインストールスクリプト（古い形式）が新しいパッケージシステムから実行されることを期待します。
しかし、ディストリビューションとパッケージは、パッケージのフォーマット以上のものです。例えば。 Debianの場合：ファイルを正しい場所に配置したい、マニュアルページを提供したい、いくつかの一般的なデーモン化スクリプトを作成したい、プログラムを多くのアーキテクチャ、さまざまなグラフィカル環境で実行してユーザーが見つけられるようにしたいディストリビューション内でも新しいpackages.packagesに精通しています。
Debianでは、ユーザーが（ソースから）パッケージを簡単にビルドできるようにして、重要な（彼にとっての）パッケージをカスタマイズできるようにします。これには、多くの上流の作成者が提供できない多くのインフラストラクチャが必要です（さまざまなアーキテクチャでの自動ビルドとテスト、および時々行われる）。また、Debian固有はライセンスの要件です。そのため、すべてのパッケージをチェックする必要がなく、パッケージまたはディストリビューションをフォークするのが簡単になります。
最後に、配布はパッケージだけでなく、一貫したパッケージによって行われます。
はい、ほとんどの.debベースのディストリビューションはすでにそれを行いますが...
Debianと関連するファミリでは、少なくとも、RPMパッケージをインストールできるalienがあります。
形式に関係なく外部パッケージをインストールすると、ディストリビューションで動作するように設計されていないパッケージを混在させる場合にも同じ問題が発生します。RPMをDEBベースのシステムにインストールする場合、そのRPMはシステムと互換性がある必要があります。 、RPMパッケージをRPMベースのシステムにインストールする場合と同じですが、それだけです。あなたはそれを行うことができますが、おそらくしたくないでしょう。
はいといいえ。 debとrpmは単なるフォーマットです。両方の形式をサポートできますが、意味がありません。パッケージは通常、ディストリビューション間、特に相互に基づいていないディストリビューション間では比較できません。
すべてのディストリビューションに同じバージョン要件がある場合、すべてのディストリビューションはパッケージ選択になります。パッケージを一覧表示することで、任意のディストリビューションをインストールできます。
しかし、ディストリビューションはサポートできるソフトウェアを提供する必要があります。アプリケーションを機能させるライブラリが維持されておらず、それ自体が他のものに取って代わられたライブラリを必要とする場合、この競合をどのように解決しますか？パッケージマネージャーはコードを移植できません。異なるディストリビューションによって選択された複数の後継者が存在する場合があります。