Linux Standard Baseの提唱するクロスフォーマット対応型パッケージAPI構想
Murdock氏の説明によると、エンドユーザの立場から見た場合、GNU/Linuxディストリビューションにおけるソフトウェアのインストール操作は、ここ数年で大きく改善されていると言う。そして同氏が特に強調するのは、dpkgおよびyumを用いた依存性の自動解決が、今では当たり前の機能となっているということだ。
一方でISVの観点からすると、様々な問題が手つかずのまま放置されている。「こうした問題については、Linuxディストリビューションに装備済みの機能と、サードパーティ系ソフトウェアベンダが利用できる機能との間で、大きな格差が存在しています」とMurdock氏は語る。「現在ベンダの多くは、Linuxを第二ないしは第三のプラットフォームとしてサポートしています。逆に言えばこれらのベンダでは、非常に雑多なパッケージシステム群の併用を強制されている訳です。そうした環境において聞かされうる最悪の出来事とは、何か既存ソフトウェアをLinuxに移植するにあたって更に別のパッケージシステムもサポートしなければならない、という事実を告げられることでしょう。また、これらが非常に低レベルなパッケージフォーマットとして位置していることも問題の1つです」
つまりMurdock氏は、こうしたISVにとって必要なものとは「想定するアプリケーションの運用上必須なすべての機能がベースとなる動作プラットフォームに用意されているかを確認するための手段です」と主張しているのである。「同じくパッケージシステムに対し、どのような処理を行うべきかを指定する手段も必要です。現状でもそのような機能は、サードパーティ系ソフトウェアを取り扱う環境中に存在してはいますが、個々のディストリビューションのパッケージ管理システム経由でアクセス可能なリポジトリに取り込まれている訳ではありません。リポジトリ外部の機能への依存度が高まるほど、加速度的に維持や管理が複雑化することは、火を見るよりも明らかです」
現在、こうした問題に関して満足できるレベルのソリューションは存在していない。確かにInstall AnywhereやBitRock Builderなどのアプリケーションを使えばWindowsライクな機能を持つインストーラを提供することは可能であるが、Murdock氏の指摘にあるように、「これらはパッケージシステムとの完全な統合はできません。こうしたものを使って得られるのは“扱いやすいtarボール”程度のものです」、という状況なのである。つまりこれらのアプリケーションを介して得られるインストーラでは、依存性を検証することも、インストールするプログラムをパッケージ管理システムに登録することもできないのだ。また個々の管理ツールは特定のパッケージシステム専用を前提としている場合が多いため、異種ネットワークをまたいだアプリケーション管理は基本的にできないと考えた方がよい。
そしてMurdock氏によると、現行の最新版LSBを用いたとしても、そうした問題が特に軽減される訳ではないとのことだ。「Linux Standard Base Core Specification 3.1」の 22章を見るとRPMは標準フォーマットであるとされているが、「それが適用されるのは5年程度前のRPMまでである」ということになり、つまりはyumによる依存性解決機能が登場する以前の話に落ち着いてしまうのである。またMurdock氏が指摘しているように、DebianベースのシステムであればLSB仕様に合致するようRPMを変換ないしインストールする外部コマンドを利用できるのは確かだが、その他のパッケージシステムに対する適応作業はまったく手が付けられていないのだ。
新たなソリューションを求めて
誰もが考えつくソリューションの1つは、autopackageのような全てのディストリビューションをカバーした汎用パッケージシステムを新規に作成してしまうことであろう。ところがMurdock氏は、こうした新規システム構築の可能性をにべもなく否定している。「それは基本的に、過去に行った全ての投資を捨て去ってしまえと言っているのと同じです」と同氏は語る。「つまりは現実性がありません」
こうした意見については、Autopackageという代替パッケージシステムのオリジナル開発者の1人であるMike Hearn氏すらも肯定するしかないらしい。「ディストリビューション側の自主的な歩み寄りを待つという姿勢をとると、決して勝利を得ることのできない千日手に陥ってしまうでしょう」とHearn氏は語る。「どのプロジェクトも、各自の方式に固執していますからね」
これと異なる方針を唱えているものこそが、昨年12月初頭にベルリンで開催されたPackaging Summitの席上でMurdock氏により提唱された新規APIの開発構想であり、それは、ディストリビューションごとに異なる各種パッケージシステムとサードパーティ製ソフトウェアとの間を橋渡しする役割を、新規に開発する1つのAPIに担わせてしまおうという考えなのである。
Murdock氏によると、こうしたAPIの機能と非常によく似たものがReal Networkのインストールスクリプトで使われており、それは使用する個々のパッケージシステムを同定した上で、然るべきディレクトリ階層にRealPlayer用ファイルをインストールするという機能である。「私どもの提唱する標準によって実質的に変更されるのは、インストーラ用スクリプトの途中にパッケージシステムとの情報交換をするステップが追加されるという点です」とMurdock氏は語る。「そしてISVについては、個々のディストリビューションごとの固有情報を使い分けるのではなく、LSBを標準として採用した上で、LSBから提供されるインタフェースのみを利用することになります。」つまりこの場合ISVにとって必要な情報は、彼らの扱うディストリビューションがLSB互換であるかを確認することだけになるのである。
「ここで考えているAPIは、RealNetworksが行っているように、独自のインストール用スクリプトを用意するだけで誰でも使えるという性質のものです」とMurdock氏は語る。「当方の希望としては、Bitrock、klik、autopackageなどのサードパーティ系管理システムでも、このAPIが利用できるようになればと思っています」
ソリューションの構築
先のPackaging Summitには主要ディストリビューションの代表も参加しているが、これらのディストリビューションが使用しているパッケージングフォーマットは、Red Hat、Mandriva、Novell系のRPMおよび、Debian、Ubuntu系のdpkgという2つの陣営に分裂しているのが現状だ。しかしMurdock氏は、こうした代表団の参加状況を1つの吉兆であると見ている。「私たちがシンプルで実用的なアプローチを検討していることに、これらのディストリビューション側も関心を示していると捉えるべきでしょう」
Murdock氏の構想するAPIの開発と標準化には、可能な限り多数のディストリビューションによる協力が不可欠だとのことだ。「標準の構築までどれだけの期間をかけるかは、それほど重要な要素ではありません」と同氏は語る。「1つの標準を定めようとする場合の最大の難関は、実際に標準を普及させる影響力のある人々を制定作業に関与させることなのです。会議室に缶詰状態になって、標準の制定が必要だという点に首肯し続けるなり、標準としてのあるべき姿に賛成票を投じることは簡単ですが、定められた標準を最終的に実装して使う側の人間を参加させて彼らの同意を得ることができなければ、全ては絵に描いたモチに過ぎません」
こうした主要ディストリビューションによる代表団の参加が新規API構築への賛意を示しているとすれば、Murdock氏の考える構想実現のための賛成票は既に過半数に達していると見ていいのかも知れない。実際、Ubuntuを代表してサミットに参加したMichael Vogt氏は「私どもはこの構想をサポートしています」と発言している。またNovellの広報責任者を務めるBruce Lowry氏も「LSBの提唱する標準化構想には、私どもも全面的に賛成しております。サードパーティ製のインストーラとネイティブのパッケージ管理システムとの間を仲立ちするインタフェースを1つのAPIに担わせるというコンセプトは、実際問題として、特定の標準を新規に定めるよりも容易に進められるでしょう」としている。同じく、Red Hatの被雇用者という立場でFedora Project Leaderを務めるMax Spevack氏も、「この方法は見込みが高いと思いますよ。既存パッケージシステム群の上位レベルで機能するAPIを用意するという方針は、新しいパッケージシステムをゼロから構築するよりも現実的な方法でしょう」と語っている。
ただし、こうした構想がコミュニティ側にすんなり受け入れられるかとなると話は別である。例えば、最大の批判意見が展開されるであろうディストリビューションはやはりDebianとなるだろうが、同コミュニティにおいてこの件に関する公的なディスカッションは未だ行われていないはずである（皮肉にもこのプロジェクトはMurdock氏が創設したものである）。より注目すべきは、この構想に関してMurdock氏のブログに寄せられたコメントの中には肯定的ないし協力的なものもかなり見られるが、それらの大方はMurdock氏の名声に引かれた意見であり、残り半数は懐疑的な見解を示しているということだ。そうした一部は今以上の改善が必要かという問いかけであり、また一部はGNU/Linux側が率先してISV側の便を図る必要があるのかという意見で、こうした多くはISVの存在をプロプライエタリ系開発者の一派に過ぎないと見なしているのである。その他にも、Windowsプラットフォームと言っても完全に統一されている訳でもなければ、Murdock氏が言うほど便利なインストレーションに仕上がってはいない、あるいはGNU/Linuxの抱えている問題はパッケージシステムの不統一だけに責任があるのではなくシステムアーキテクチャ的な差異にも起因している、という指摘がなされている。実際いくつかの意見として、現行の各種パッケージシステムの完成度は非常に高く、そうした知識の取得はISV側の責任となるはずだ、という主張も存在しているのだ。
その他のコメントの中には、サードパーティ製インストーラがシステムに加えた変更情報がフィードバックされない場合、あるいは、デザイン的に不備のあるインストーラによって不用意にファイルが上書きされる危険性といった、潜在的なセキュリティ問題に関する不安を提示しているものもある。
こうした問題点については当のMurdock氏自身も1つの懸念を抱いており、それは先のサミットへの参加者が主要なパッケージシステムの関係者に限定されていたということである。もっとも同氏としては、このプロジェクトが進展するにつれ参加側の枠組みも広がってゆくことを期待しているようだ。「Gentooなりその他のプロジェクトが即座に参加を表明すれば、諸手をあげての大歓迎となるでしょう」と同氏は語る。「また、この記事を読んでパッケージシステムに興味を持たれた方がおられましたら、www.freestandards.orgにアクセスし、Workgroupsのページにあるpackagingのリンクにアクセスしてくださいますようお願いする次第です」
将来的なタイムライン
Murdock氏の提唱するAPIの現状だが、同氏の語るところでは「1つの標準としてどのような機能を定めておくべき必要があるのかについて、ごく基本的なアウトラインが存在しているだけです。仕様と言えるものが出来上がるのは、半年くらいは先になるでしょうね」という状態だそうだ。
これはMurdock氏による希望的観測であろうが、仕様さえ定まればこのAPIはLSBのバージョン4.0に取り込まれるようになるので、広範に実装されるようになるのは「1年から1年半は先の話でしょう」と説明されている。その頃になれば次回リリース版のRed Hat Enterprise LinuxおよびSUSE Enterpriseが公開されており、Debianベースのディストリビューションにおけるdpkgの改訂も終わっているだろうとのことだ。
Murdock氏の語る「ISVに対し“この標準はもう普及しているので、安心して採用できますよ”と言えるようになる」という時代は、そうした状況になってからの話ということになる。
そうした時期が訪れるまでにMurdock氏およびLSBが行うべき課題は、具体的な仕様やコードの構築と並行して、各種ディストリビューションサイドとの交渉を進めることである。「みんなで歩調を合わせてダンスを踊りましょう、というようなものですね」と同氏は締めくくった。
Bruce Byfieldは、コンピュータジャーナリストとして活躍しており、NewsForge、Linux.com、IT Manager’s Journalに定期的に寄稿している。
