rpmパッケージとdebianパッケージの両方をサポートできるLinuxディストリビューションを理論的に構築できるかどうか疑問に思っています。

両方をサポートするディストリビューションがありますか？

そして、そうでない場合でも可能ですか？

Bedrock Linuxはこれを行います。私がこれをやったと言っているわけではありません。

両方をネイティブにサポートするディストリビューションは存在しないと思いましたが、開発中のBedrock Linuxがあることがわかりました（情報についてはiMalinowskiに感謝します）。他のディストリビューションでは、ある形式から別の形式に変換するなどの変換ツールを使用できます。十分な時間とエネルギーがあれば、ソフトウェアベースのものは何でも実行できます。そのため、そのようなディストリビューションを構築することは可能です（ただし、パッケージの機能とパッケージの違いを考えると、非常に困難です）。alien.deb.rpm

しかし、このすべては、おそらくあなたが（まあ、どこでもAを提供し、どこからでもパッケージをインストールする可能性があるため、両方のパッケージフォーマットをサポートすることは、人生をより簡単になるだろうという考えから、茎.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が、そのようなハッキングから必然的に発生する問題のトラブルシューティングに多大な努力を注ぐことを期待する必要があります。

まあ、alien（など）の間で変換できる（マニュアルページ）がありますが、実際の問題は依存関係（ソフトウェアの異なるパッケージ名）と構成ファイルの場所を処理することから来ると思います。rpmdeb

もちろん、両方のタイプのパッケージがディストリビューション自体に由来する可能性があるということであれば、おそらくそれを回避することができますが、なぜ誰もがそれを行うのでしょうか... 、私はdpkgデータベースの読み方を知らないと思うのでrpm、その逆も同様です。

はい、可能ですが、ディストリビューションを台無しにします。

パッケージは単なる形式ではなく、ある形式から別の形式に簡単に移植できます。

注：パッケージインストールツールは、すべてのパッケージ、バージョン、依存関係、構成ファイル、インストール前およびインストール後のスクリプトの一覧を一元管理する必要があるため、移植する必要があります（あるパッケージを別のパッケージに置き換える場合、形式、アンインストールスクリプト（古い形式）が新しいパッケージシステムから実行されることを期待します。

しかし、ディストリビューションとパッケージはパッケージの形式以上のものです。たとえば、Debianの場合：ファイルを正しい場所に配置し、マニュアルページを提供し、一般的なデモスクリプトを作成し、プログラムが多くのアーキテクチャ、さまざまなグラフィカル環境で実行され、ユーザーが見つけられるようにします。ディストリビューション内でも新しいpackages.packagesに精通しています。

Debianでは、（ソースから）ユーザーがパッケージを簡単にビルドできるようにして、重要な（彼にとって）パッケージをカスタマイズできるようにします。これには多くのインフラストラクチャが必要であり、ほとんどのアップストリーム作成者は提供できません（さまざまなアーキテクチャでの自動ビルドとテスト、および時々行われます）。また、Debian固有のライセンス要件もあるため、すべてのパッケージをチェックする必要なく、パッケージまたはディストリビューションをフォークするのが簡単です。

最後に、配布はパッケージだけでなく、一貫したパッケージによって行われます。

はい、ほとんどの.debベースのディストリビューションはすでにそれを行っていますが、...

Debianおよび関連するファミリーには、少なくともがありますalien。これにより、RPMパッケージをインストールできます。

フォーマットに関係なく外部パッケージをインストールするときにディストリビューションで動作するように設計されていないパッケージを混在させると同じ問題が発生します-RPMをDEBベースのシステムにインストールする場合、そのRPMはシステムと互換性がある必要があります、RPMベースのシステムにRPMパッケージをインストールしているように、それだけです。できますが、おそらくしたくないでしょう。

はいといいえ。debとrpmは単なるフォーマットです。両方の形式をサポートできますが、その意味はありません。通常、パッケージはディストリビューション間で比較できません。特に、互いに基づいていないディストリビューションは比較できません。

すべてのディストリビューションのバージョニング要件が同じ場合、ディストリビューションはパッケージの選択のみになります。パッケージをリストすることにより、任意のディストリビューションをインストールできます。

ただし、ディストリビューションは、サポートできるソフトウェアを提供する必要があります。アプリケーションを動作させるライブラリが維持されておらず、それ自体が他の何かに取って代わられたライブラリを必要とする場合、この競合をどのように解決しますか？パッケージマネージャーはコードを移植できません。異なるディストリビューションによって選択される複数の後継者が存在する場合があります。