rpmとdebパッケージ形式が1つの標準システムに統合されていないのはなぜですか？
私はこの質問 質問 をスタックオーバーフローで受けましたが、閉じられました "本当の質問ではない"。
そこで、このスタックエクスチェンジが「ソフトウェア開発に関する概念的な質問」用であると仮定して、すべてのゴロゴロを削除し、その質問をここに投稿することにしました
主な質問はタイトルにあります：rpmとdebパッケージのフォーマットが1つの標準システムに統合されていないのはなぜですか？
このようなフォーマットの断片化は悪いので、これは私たちがしなければならない非常に重要なステップだと思います。独立したソフトウェア開発者だけでなく、vim、python、Ruby、nodejsなどの独自のパッケージを再発明する他のツールや言語にとっても、php、Eclipse、その他多数
それは別の標準を作成し、rpmとdebの両方をサポートする必要があるためです。
自然な方法は、人が他の人の使用をやめるほど優れていることを示すことです。
これは、DEBとRPMは本質的に物事の異なる方法であり、2つの別個のシステムをもたらす一種の不一致と見なされる可能性があるためです。
この問題に関する興味深い議論があります： https://unix.stackexchange.com/questions/634/what-are-the-pros-cons-of-deb-vs-rpm
Linux Standards Base プロジェクトでパッケージ形式を標準化する試みがありますが、Debianは入力の提供から除外され、RPMのサブセットがパッケージ形式として選択されたようです。ウィキペディアから：
RPMパッケージ形式の選択
LSBは、ソフトウェアパッケージをLSB準拠のインストーラー[11]として提供するか、（できれば）RPM PackageManager形式の制限された形式で提供することを指定しています。[12]
このパッケージ形式の選択により、RPMと互換性のない他の多くの既存のパッケージ形式を使用できなくなります。これに対処するために、標準は、システムが独自のパッケージに使用する必要のあるパッケージ形式を規定していません。RPMがサポートされ、サードパーティのディストリビューターからのパッケージを適合システムにインストールできるようにする必要があるだけです。
Debianの制限
Debianには、初期の段階でLSBのオプションサポートが含まれています。「woody」のバージョン1.1と「sarge」のバージョン2.0、その後「etch」のバージョン3.1、「lenny」のバージョン3.2です。外部LSB準拠のRPMパッケージを使用するには、エンドユーザーはDebianのAlienプログラムを使用してそれらをネイティブパッケージ形式に変換してからインストールする必要があります。
LSB指定のRPM形式には、RPM機能のサブセットが制限されています。これは、Alienまたは他のパッケージ変換プログラムで.debに変換できないRPM機能の使用をブロックするためです。また、各形式には他の形式にはない機能があるため、その逆も同様です。実際には、すべてのLinuxバイナリパッケージが必ずしもLSB準拠であるとは限らないため、ほとんどのパッケージは.rpmと.debの間で変換できますが、この操作はパッケージのサブセットに制限されています。
Alienを使用することにより、Debianはすべての目的と目的でLSB互換になりますが、lsbパッケージの説明によると[13]、パッケージの存在は「DebianがLinux StandardBaseに完全に準拠していると私たちが信じていることを意味するものではありません。そして、DebianがLSBに準拠しているという声明として解釈されるべきではありません。」[13]
一般に、DebianはLSBに準拠するよう努めていますが、他にも制限がある場合があります。[14]
私が読んだものとは、機能セットが非常に異なるため、2つをマージするのは非常に困難です。少なくとも標準化したいという欲求はあるようですが、私が賭けをしなければならない場合、Debianのpackagae管理システムがおそらく最終的に引き継がれると言えます。パッケージまたはDebianパッケージを最初に実行します。
独立したソフトウェア開発者が簡単にできるようにフォーマットが設計されていないため、独立したオペレーティングシステムのディストリビューターが簡単にできるように設計されており、RedHatとDebianは他のフォーマットが使用しているフォーマットを気にする必要がありませんでした。エレキギターでヴィヴァルディを弾くのがなぜそんなに難しいのかと尋ねるようなものです。
そうは言っても、人々は試みました。 AutoPackage は、私が認識している最も注目すべきものです。ネイティブパッケージマネージャーは置き換えられません置き換えませんが、それを補完します。これが、1リングからルールへの変換よりも成功した理由です-すべての試み。他の人が一般的に使用するものは Alien で、これはある形式から別の形式に変換できます。最も重要なソフトウェアが1つの形式でのみパッケージ化されている場合のもう1つの一般的な解決策は、その形式をサポートするディストリビューションに切り替えることです。
独立したソフトウェア開発者に関する限り、ほとんどは3つのアプローチのいずれかを採用しています。一部のオープンソースプロジェクトは、ソース形式で配布し、バイナリ形式を処理するために配布を頼りにしています。 Linux上のクローズドソースソフトウェアは通常、ある種のカスタムbashスクリプトインストーラーとともに配布されます。さらに、オープンソースおよびクローズドソースの開発者は、rpmおよびdeb形式の両方を頻繁に配布します。すべてを設定するのに1営業日かかる場合があり、それを心配する必要はほとんどありません。それがそれほど簡単でなかったら、より多くの人々が変化を求めているでしょう。