Linux開発者がユニバーサルパッケージフォーマットを作成できないのはなぜですか？

ベンダーバイナリパッケージ形式の選択は、マーフィーの法則の形式によって決定されるようです。使用しないすべてのディストリビューションにはパッケージがあります。（関連：ソフトウェアスタックの配布依存関係を満たす配布は存在しません）。

これは、「ビルドワンス、どこでも実行」パッケージ形式の出現を見ていない、政治的な問題なのか、それともより深い問題なのか？

これについてジョエル・スポルスキーを引用するのが適切だと思われる：

（ちなみに、ブログのシンジケーションフィード形式の難解でありながら政治的に荷電された世界をフォローしている人にとっては、同じことが起こっていることがわかります。RSSはいくつかの異なるバージョン、不正確な仕様、そして、Atomと呼ばれるさらに別の形式を作成することにより、クリーンなすべてのものまでの試みは、いくつかの異なったRSSのバージョンを加えたアトムの1つのバージョン、不正確な仕様や政治的な戦いの多くをもたらした。あなたは第3の選択肢を作成することにより、2つの相反する力を統一しようとすると、最終的には3つの反対勢力になります。何も統一しておらず、実際には何も修正していません。）

（強調を追加）

Linux用の（少なくとも）2つのパッケージングシステムがあります。それは実際には良いことです。単一のシステムは、単に3番目のシステムを作成します。

これには多くの理由があり、物事を視野に入れるために少し歴史があります。

「Linux」について話すとき、私たちが一般的に言及しているのは、多くの異なるLinuxディストリビューションの 1つであることを忘れないでください。「Linux」は、実際には単なるオペレーティングシステムカーネルです。

Linuxの当初の目標は、PC（当初は386）で実行されるUnixベースのシステムを作成することでした。最初のステップは、カーネル自体を作成することでした。一方で、Linus Torvalds氏は、カーネルに取り組んでいたリチャード・ストールマンは、自分で働いていたフリーの下で、UnixシステムGNU（GNUのはないのUnix）プロジェクト。要するに、GNUには関連するユーティリティ（Cコンパイラ/ライブラリ/ビルドツール、シェル、テキストエディタなど）がありますが、実行するコアがなく、Linuxにはコアがあり、その上で実行して、大衆に役立つようにします。

このコンバージェンスは、正式にはGNU / Linuxとして知られるようになりました。多くのディストリビューションがまだGNU / Linuxディストリビューションと呼ばれていることがわかります。

GNU / Linuxの自由で開かれた性質のために、だれでもそれを手に入れ、特定の好みに合わせてバンドルされたシステムを作成できます。その結果、これらのシステムを作成するためにさまざまな構成方法の多くの異なるストリームが使用され、それぞれに適合するほぼ同じ数の異なるパッケージ管理システムを作成するという副作用がありました。

それぞれの完全なシステムには、長年にわたってこだわる独自の強力なフォロワーがいて、今日のようになりました：RPM、APT / dpkg、Gentoo's Portageのような広く使用され、深く根付いた安定したパッケージ管理システム。

Autopackageなどの問題を解決しようとしているプロジェクトがありますが、サポートされているさまざまなパッケージ管理システムの継続的な進化は、従うべき多くの動いている目標があることを意味します。

一部のソフトウェアベンダーは、必要な特定のバイナリと依存関係のコピーを、特定のシステムで動作する1つの大きなパッケージにバンドルしています。

とにかく、同じパッケージ形式を使用しても役に立ちません。他のディストリビューションで同じパッケージを使用することはできません。同じディストリビューションの異なるバージョンで使用することはできません。また、パッケージをビルドしても同じ問題が発生する可能性があります。

パッケージをインストールするには、パッケージのビルド中に形成される依存関係を満たす必要があります。パッケージをビルドするには、ビルドの依存関係を満たす必要があります。そして、これらのことは変わります。変更を実装できるようにするには、変更後に機能するように変更できるパッケージのみをサポートする方が簡単です。

すべての依存関係が同じ場合、異なるディストリビューションまたは同じディストリビューションの異なるバージョンにはなりません。

「ここでは発明されていない症候群」が少しあると思います。DebianのパッケージングシステムはRedHatよりも前のものですが、多くの点で優れていますが、RedHatの切り替えは決して見られません。代わりに、多くの人が「apt-rpm」を使用しており、rpmファイルを使用したaptの利点のいくつかを提供しようとしています。

.debに移動するだけです:-)

zero-installやautopackageなど、いくつかの仮の形式がありました。残念ながら、何も牽引力を得ることができませんでした。

クレタス、ウェイン、イニーはこれにかなりよく答えたと思う。本当に付け加えたいのですが、大したことではありません。私は、Gentoo（portage）、SUSE（rpm / zypper）、およびOpenBSD（パッケージとポート）がある混合環境で働いています。それらのいずれかにパッケージをインストールすることは難しくなく、私は彼らが使用しているフォーマットを本当に気にしません。

ソフトウェアのパッケージングの観点からも、それほど難しくありません。Gentoo、RPMベースのディストリビューション、またはdebベースのディストリビューションであっても、実際には、ソフトウェアを構築してメタデータを追加するためのレシピを作成するだけです。パッケージ化しようとしているもののビルドシステムが完全に狂っていなければ、通常はパッケージを作成するために栄光に満ちたシェルスクリプトを書くだけで済みます。

さて、tarボールには常に静的にコンパイルされたバイナリがあります.... ;-)

それは単なるカーネルであるため、「Linux」の標準バイナリインターフェイスの定義はありません。奇妙なことに、ソフトウェアスタックはカーネル以上のものとインターフェイスする必要があり、数百の異なるソースツリー間で標準のABIを維持するという特別な課題を提示します。

優れたパッケージングツールのトピックでは、Debian GNU / Linuxが優れたバイナリパッケージング形式であることを好みます。標準のツールとアプリケーションに対する私のニーズの90％を満たしました。残りの10％は、フリーでないコンポーネントまたはバグの多い共有ライブラリの依存関係が含まれるため、ソースから構築されます。これらのアプリケーションをデプロイする必要がある場合、実稼働クラスター用のカスタムバイナリを構築します。

ビルドワンスを取得するには、いくつかの重要な機能が必要な同じディストリビューションを全員に強制することなく、どこでもパッケージ形式を実行します。

• グローバルに一意なパッケージの命名。2人の人/ディストリビューションが同じ名前の異なるパッケージを個別に作成できないようにします。

• パッケージの要件が競合する場合に、異なるバージョンのライブラリを並行してインストールする機能。ディストリビューションは、使用する各ライブラリのバージョンを決定し、すべてのパッケージがそのバージョンを使用するように強制できます。ディストリビューション全体で機能するシステムは、より柔軟でなければなりません。

ゼロインストールは、次の両方の機能を提供します。

• 名前はURIです（例：http : //rox.sourceforge.net/2005/interfaces/ROX-Filer）。ドメインの所有者のみがデフォルトでその名前空間内にパッケージを作成できます。

• 各パッケージの各バージョンは、独自のディレクトリに配置されます。各アプリケーションは、互換性のあるバージョンで、必要なライブラリのみを認識します。

たとえば、Editアプリケーションは、次のようにPython <3に依存しています。

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

参照：http : //www.osnews.com/story/16956/Decentralised-Installation-Systems

[注：私は0install開発者です]