きびしい残暑が収まると一気の秋の気配が深まり、筆者の実家の回りでも稲刈りの時期になりました。実りの秋に便乗するわけではありませんが、筆者が取りまとめ役をやっているPlamo Linuxも、1年ぶりの新バージョンのリリースに向けて最終的な調整段階に入っています。そのような状況を反映して、今回は普段の「ソースコードリテラシー」とは少し趣向を変えて、ディストリビューション作成の裏側的な話をしてみようと思います。

新バージョン開発の開始

ディストリビューションは多数のソフトウェアパッケージから構成されています。比較的規模の小さなPlamo Linuxでも、最近ではX Window Systemを構成するパッケージが細かく分割されたこともあって、GNOMEやKDEまでインストールすると900を超えるパッケージが必要となります。

これら多数のパッケージが相互に協働しながらひとつのシステムを作りあげていくわけですが、パッケージの間にはさまざまな依存関係があり問題を複雑にしています。依存関係は動作に必須のライブラリから、あれば便利な付加的機能までさまざまですが、それらの依存関係の中でも、Cコンパイラ（gcc）とCライブラリ（glibc）はほぼ全てのパッケージが必須の依存関係を持つパッケージで、システムの最も基礎となる部分です。

Linuxやその元になっているUNIXはC言語で開発されているOSなので、CコンパイラやCライブラリに問題が生じると、他の全てのパッケージが影響を被ることになります。そのため、CコンパイラやCライブラリの更新には慎重を期す必要があります。

最近のgccやglibcでは過去のバージョンとの互換性は十分考慮されており、古いバージョンのgccやglibc用に作成したバイナリファイルでもたいていそのままで動作します。しかし、新しいバージョン用に作成したバイナリファイルは、ライブラリの新機能を使っている場合、その機能を持たない古い環境では動作しなくなります。

このような理由から、Plamo Linuxではgccやglibcの更新はバージョンが大きく変る場合に留めており、新バージョンの開発はまずgccやglibcの更新から始めることにしています。Plamo-4.2系は、2年ほどの間に4.21、4.22とアップデートしてきましたが、gccやglibcは最初に採用した3.4系、2.3系をそのまま引きずっており、やや古さが目についていましたので、今回も新バージョンの開発は新しいgcc、glibcを採用するところから始めました。

Plamo-4.5の変更履歴（Change.Log）を見ると、今年の1月21日にglibc-2.7、gcc-4.2.2にそれぞれ更新しています。ここからPlamo-4.5の開発作業が公式に始まりました。

パッケージ更新の日々

前述のように、最近のgccやglibcは以前のバージョンとの互換性が高く、古い環境で作成したアプリケーションでもたいていそのまま新しいライブラリの上で動きます。このような特徴を使って、動いているPlamo Linux環境（4.22）上でgccとglibcをまず入れ替え、新しいgccとglibcでパッケージを作り直していきます。

変更履歴によると、1月下旬はほぼ毎日のようにパッケージを更新しています。これらパッケージの更新は、元々動いていたソフトウェアを再度入れ直すという、動作や表示が大きく変わることもない地味な作業ですが、基盤的なパッケージで設定を間違えるとそれらを利用して作成するパッケージ全てに影響が及んでしまうので、注意深く進める必要があります。個人的には、このあたりの作業を「賽の河原の小石詰み」と自嘲したりしています。

比較的独立性の高いパッケージならば、このような漸進的な更新で変更していくことができますが、相互に密接に関連しあった一群のパッケージはまとめて更新する必要があります。たとえばXlibを元に構築されているX Window Systemや、GTK/Qtといった高機能なウィジェットを元に構築されているGNOME/KDEといったデスクトップ環境は、半分だけ更新して一休み、というわけには行かず、更新を始めたら全て更新してしまわないと正しく動作してくれません。これら大規模なパッケージの中でも、Plamo-4.5の開発の中ではX11R7.3への更新が一番大変でした。

Plamo-4.2系で使っていたX11はR6（Release 6）と呼ばれるバージョンで、開発主体こそX.Org Foundationに変ったものの、ソースコードはMITのAthena Projectで開発されていた頃と同様、xcディレクトリ以下に展開された全てのファイルをmake Worldコマンドでコンパイルする形式でした。しかしながら、X Window Systemが進化してゆくにつれ、大規模で複雑なソースコードをまとめて管理することが困難になり、R7以降のX11では1つ1つのライブラリやアプリケーションを個別に管理するように変更されました。

その結果、コンパイルの方法も、かってのように make World一発で全てを作りあげるのではなく、ライブラリやアプリケーションそれぞれをcofigureスクリプトで設定してmakeし、インストールしていく形式に変更されました。この変更の結果、プロトタイプ宣言やヘッダファイル、必須のデータファイルなどを先にインストールしておかなければライブラリはコンパイルできず、ライブラリがそろわないとアプリケーションはコンパイルできない、といったX Window Systemのパッケージ内部での依存性も生じることになりました。

おかげでPlamo-4.2系で使っていたX11R6用のビルドスクリプトは使えなくなってしまい、かと言って300以上に分割されたソースコードそれぞれにビルドスクリプトを新しく作るのも大変だし、さてどうしたものか…、としばらく悩みましたが、結局開発元のX.Org Foundationが提供しているビルドスクリプトに手を加えて、Plamo用のパッケージを作成するようにしました。こういうと多少の工夫で簡単に作成できたように聞こえますが、変更履歴を見ると、ディレクトリ構成のすりあわせ等の調整のため、1月の末から2月にかけて都合3度ほど全体をビルドし直しています。

βリリース、その後

X Window Systemの更新後もKDE 4.0やGNOME 2.22といった大物の更新があったり、4月、5月は多忙で開発が進まなかったり、GNOMEやKDEの複雑な依存関係を整理するためにパッケージ群の配置やインストーラの扱いを見直したり、といった日々を重ねつつ、ようやく8月の下旬からβ版としてメーリングリスト等でアナウンスしてテスターを募集しました。

β版を公開する前には、開発者（メンテナ）の間でα版を常用環境にできる程度に調整したつもりでしたが、テスターの人数が増えると見落していた不具合がいろいろと見つかります。今回はPlamo LinuxのWikiページに4.5用の不具合情報のページを設けたこともあり、2ヵ月ほどの間に60件を超えるトラブル情報が寄せられ、その多くが正式リリース前に解決できました。

10月の上旬現在、rc（release candidate）1版のテストに入っており、今後大きな問題が発覚しなければ、10月中には正式版のリリースができそうです。

ソフトウェア開発の慣例として、βリリースの段階に入るとバグFix以外の変更は行うべきではありません。そのため、Plamo Linuxでも8月のβ版の公開以後はセキュリティ関連の修正等の緊急性の高いものを除き、収録しているパッケージの更新は停止しています。

しかしながら、OSSの進化は止まることがなく、更新を2ヵ月ほど停止しただけで、すでに古くなってしまったソフトウェアがいくつもあります。前述のようにX Window SystemはR7.4が公開されましたし、GNOMEも2.24が公開されました。その他、Pythonも新しい2.6系が公開され、GIMP-2.6など新しいバージョンのPythonを必要とするソフトウェアも増えてきたので、そろそろ対応を考えないといけません。これらをPlamo-4.5へのアップデートとして対応するか、文字コードなどを見直した新しい5.0のシリーズの開発へ軸足を移すか、しばらくは悩ましい日々が続きそうです。

ディストリビューションの開発というのはこのように終わりのない作業です。特にPlamo Linuxのようにボランティアで開発しているディストリビューションでは、開発者（メンテナ）の人たちもそれぞれ本業を持っているので、開発サイクルのリズムが合わずに調整に苦労することもしばしばです。

さまざまな苦労もありますが、苦労して作ったパッケージほど思い通りに動いた際の喜びは大きくなります。何日も悩み続けた難しいパズルが、少し視点を変えたら解法が見つかってスカッと解けた時に感じる快感、自分の投げたアイデアがメーリングリストなどで叩かれたり強化されたりしながら洗練されていく際の驚き、直接面識の無い人からネット上で届く感謝や賞賛など、金銭的には何らメリットが無くても、このような精神的な喜びがディストリビューションの、そしてその元であるOSS開発の原動力になることを実感しています。