openSUSE:Libzypp の概要

移動先: 案内, 検索

Libzypp

SUSE Linux 10.0 では パッケージ管理 に関して、下記のようなプログラムを提供していました:

  • YOU - YaST オンライン更新 (更新のみ)
  • YaST パッケージマネージャ ("yast sw_single"; インストールと削除のみ (更新を含まず))
  • YaST と YOU の代替である apt-rpm

SUSE Linux 10.1 では、 libzypp と呼ばれる新しいパッケージマネージャ解決器ライブラリを統合しました。

libzypp は SUSE の YaST2 パッケージマネージャと Ximian の libredcarpet を統合した仕組みで、 Novell は利用していた 2 つのソリューション (Red Carpet と YaST パッケージマネージャ) を統合して、最適なシステムを作成するよう決定を下しました。

SUSE Linux における利点は下記のとおりです:

  • 以前よりもよりよい解決器を提供できること
  • なぜパッケージがインストールされるのか、もしくはなぜ解決方法が存在しないのかをより詳しく表示できること
  • 我々のパッケージマネージャに対して何年もの間追加され続けてきた、すべての機能を統合できること
  • コマンドラインのインターフェイス ("rug") が用意されること
  • パッケージと修正の処理を統一的に行なうことができること
  • パッケージ更新時にも依存関係を処理できること
  • パッケージをとりまとめて管理できること ("パターン" と呼んでいます)
  • リモートから管理できること (SUSE Linux 10.1 ではまだ利用できませんでした)
  • インストール時点で追加リポジトリを設定できること
  • 異なる複数のリポジトリを設定している環境で、より柔軟な処理を実現できること (例えば、それぞれのリポジトリで独自のパターンを設定できるなど)
  • 言語やハードウエアをベースにした追加の依存関係 (フォントや翻訳、ドライバなど) を設定できること

Libzypp の歴史

  • SuSE GmbHXimian の合併後、 Novell は自社製品として公開していたパッケージ管理システム YaST パッケージマネージャと Red Carpet を統合し、異種混合型の巨大システムを管理するよう設計された Zen Management Network を作成することを決定しました。そこで作成されたマネージャ ZYpp は、 ZMD デーモンと共同でうまく動作していたのですが、一般的なディストリビューションに対しては適切でない作りになっていて、 openSUSE 10.1 リリースでは期待通りに動作しない結果になってしまいました。
  • openSUSE 10.2 リリースでは、上記のような欠陥を修正していて、 libzypp も v2 となって改良が図られました。そのため、 ZMD は 10.3 で最終的かつ恒久的に廃止され、商用の企業向け製品にのみ採用されることとなりました。さらに zypp v3 では、 openSUSE に対して比較的良好なパッケージマネージャを提供し、実装内の欠陥からもたらされる性能面の問題が解決され、ようやく他のパッケージ管理システムと同等のものを提供できるようになりました。
  • OPIUM (Optimal Package Install / Uninstall Manager; 最適型パッケージインストール/アンインストールマネージャ)[1a] や Mancoosi[1c] のようなプロジェクトでは、 SAT ソルバー (充足可能性問題の解決器) を利用して依存関係の問題を解決しようとしていました。 Apt[1a][1b] などの従来型の解決器では、時折受け入れがたい結果を表示することがありますが、 SAT ソルバーの場合は複雑性理論を利用しているため、これらとは基本的に異なる動作をします (Apt および Aptitude とのアルゴリズムの違いについては、 [3] をお読みください) 。 zypp スタックに対しては、有名な minisat ソルバーをベースにした解決器アルゴリズムを統合する決定を下しています。
  • 何か月かの作業ののち、もたらされた結果はさらなる希望を与えました: zypp v4 のベンチマーク結果は、同じマシンにおける YUM や Smart と比べて明らかに (グラフについては [5] をご覧ください) 良好なもので、かつ Smart の "ユースケース" も適切に管理されていることを示していました。また、この新しい zypp における驚きの機能として、物理的なパッケージに対する推奨機能が追加されていたことが挙げられます。たとえば新しいカメラをインストールする必要がある場合、ハードウエアを接続して "zypper update" コマンドラインを実行 (もしくは YaST を実行) するだけで、オンラインのリポジトリから適切なドライバを取得するように動作するようになっています。
  • Zypp は openSUSE ディストリビューションとは独立したプロジェクトとして活動しているものであるため、事実上の標準である yum といくらかの互換性がある [7] ほか、他のディストリビューションでも利用できる仕組みになっています: たとえばグラフィカルなユーザインターフェイスである PackageKit は zypp のバックエンドを利用しています。また、 [[Portal:Build_Service|openSUSE Build Service] の柔軟性により、 Fedora や Mandriva Linux [8] などでも ZYpp パッケージマネージャを利用できるようになっています。

FAQ

1 - 既存のソリューションを利用せず、新しいライブラリを作成したのはなぜでしょうか? 単純に Apt を利用すれば十分だったのではないですか?

SUSE Linux 10.0 のリリースのあと、 (RPM 上で動作する) 既存のパッケージ管理インフラストラクチャを次のステップに移行させる必要を感じたためです。具体的には、下記のようなサポートを追加ないしは大幅に改善する必要があるものと考えていました:

  • 複数のソフトウエアリポジトリへの対応、特に YOU と標準リポジトリの共有
  • アドオン製品の処理
  • 機能の豊富なローカルクライアント (zypper や更新アプレットなど)
  • 集中管理型の管理インターフェイス
  • パターンや修正などの機能
  • C++ API
  • リポジトリへの署名

2005 年時点で、既存のオープンソースツールやそれらの成熟性を確認したところによると、上述のような要件を満たすものが存在しないのは明らかであったほか、 Ximian や SUSE, そして現在では Novell が、既存の Linux 管理インフラストラクチャソフトウエアを開発するのに適切であったことも理由に挙げられます。

このような理由により、既存のピースを応用して要件に適合する新しい実装を作成し、最適なアイディアを構成する決断を下しました。


2 - 機能面で、 libzypp は他のツールと比べるとどうなのでしょうか?

libzypp の機能 として一覧をまとめてあります。 RPM をベースにした様々なソフトウエア管理ソリューションとの機能比較については、 ソフトウエア管理でのコマンドラインツール比較 をお読みください。


3 - 他の類似ツールと比べて、 libzypp の性能はどれくらいでしょうか?

libzypp の初期バージョンは、何もない状態から作成した新しいライブラリであることから、比較的遅いままでした。私たちはこの問題を解決すべく、リリース済みのディストリビューションから得られる経験やユーザのフィードバックをもとに定期的な性能改善を実施してきました。現在では SAT ソルバーライブラリの取り込みもあって、利用可能なものの中で最も高速なパッケージマネージャのうちの 1 つになっています。

詳しくは Libzypp/パッケージ管理 をお読みください。


4 - What about standardization and upstream use of libzypp and related technologies?

RPM の依存関係に新しい種類を追加する作業などとともに、私たちは技術の推進に力を注いでいるほか、 rpm-md リポジトリのアップストリームに対しても機能拡張を推進しています。 SUSE 固有の機能をアップストリームに推進するようなことはありませんが、 LSB におけるパッケージングのほか、将来的に一般的となるはずの SUSE 固有の機能を、 RPM5 プロジェクトに推進するような活動などを行なっています。


参考資料


その他


外部リンク

  • ZYpp (英語版 Wikipedia)