つい先日新年を迎えたかと思っていたら、あっと言う間に1月も終りに近づいてしまいました。そのため、タイミング的にはやや旧聞に属する感もありますが、昨年の年末ぎりぎり、12/31付けでPlamo64-1.0をリリースしたことを報告します。

思えば、新しいCore i7 CPUのマシンを組んで、その上で使うためにPlamo Linuxを64ビット環境へ移植し始めたのが一昨年の秋ごろだったので、64ビット化作業は丸一年以上かかったことになります。Plamo64の開発過程は本連載でも適宜紹介してきましたが、今回はまとめの意味を込めて開発過程を振り返ってみましょう。

開発の開始

Change.Logの記載を調べると、Plamo64についての記載が入り出したのは2010年（平成22年）の10月ごろでした。

この年の9月1日にPlamo-4.73を公開し、4.7系の開発作業が一段落したのに合わせて、新しいPCを組み立て、64ビット用の開発環境を構築し始めました。64ビット用の開発環境はクロスコンパイルの勉強のつもりで、CLFSの手順を参考に、

• 32ビット環境（Plamo-4.73）上で64ビット用のバイナリを出力できるクロスコンパイル用ツールをビルド
• それらのツールを使って64ビット用の開発環境をビルド
• 64ビット用の開発環境を使って64ビットネイティブな環境をビルド

という手順で進めていきました。このあたりの詳細は本連載の16回目に取りあげています。

Change.Logによると、10月27日ごろから64ビット版の開発環境用のパッケージが登録されはじめ、11月の上旬ごろにはほぼ64ビット用パッケージのコンパイルに必要な環境が整ってきました。

ただし、この段階ではインストーラが64ビット版に未対応でした。そのため、インストール不要で動作するP-Plamoの手法を使って、Plamo-4.73上で64ビット用の開発ツールが動く32ビット/64ビット混在環境を作り、メンテナの人たちに公開して、開発作業を分担してもらえるようになりました。このあたりの詳細は本連載の17回目に紹介してみました。

P-Plamoの場合、インストール作業は不要なものの、メモリ上に作成したramdisk上で動作するので電源を落すと初期化されてしまいますし、カーネルや開発環境自体はDVDに書き込まれているため更新できません。

そのため、開発を本格化するためにはHDD上にインストールするためのインストーラが必須になるわけですが、インストーラはファイルシステムの作成や初期化、パッケージの展開、各種設定ファイルの作成など、さまざまな機能を持つ複雑なソフトウェアなので、ある程度開発を進めないと必要な機能が揃いそうにありません。

さてどうしたものか、、としばし悩みましたが、x86-64 CPUの場合、64ビットのロングモードの中に32ビットのバイナリを動かす互換モードが存在するので、その機能を使えば既存の32ビット用のインストーラを流用できることに気づきました。そこで、インストーラでは、カーネルこそ64ビット用にするものの、ユーザ領域のライブラリやコマンド類は既存の32ビット用のバイナリを流用することにしました。こうすればカーネルを入れ替えるだけでx86用とx86-64用のインストーラを共有できるので、x86環境にもメリットがあるでしょう。

インストーラも何とかなり、メンテナの人たちからのパッケージも集まりだしたので、2011年（平成23年）1月上旬にはインストール可能な最初のDVDイメージ（Plamo64-0.1）を公開しました。

開発の長い道程

HDD上で起動できるようになれば、後はその環境上で必要なパッケージをビルドしていけばいいわけですが、Plamoは小規模なディストリビューションとはいえパッケージ数は1000を越えているので、パッケージを揃えていくにはメンテナの人たちの協力が必須です。

今回も初期の不安定なころから、メンテナの方々に献身的な協力をいただき、多数のパッケージを作成してもらいました。

開発が軌道に乗ってくると、ディストリビューションのとりまとめ役の仕事は、集まってきたパッケージを整理しつつ適当なタイミングでDVDイメージを更新していくことになります。その際、新しい試みとしてDVDイメージを作った日付を記録してみることにしました。

Plamo LinuxのDVDイメージはmkisofsコマンドで作成しています。mkisofsには、DVDからブートするための設定や不要なディレクトリを除外する指定など、オプションが多数存在し、それらを一々コマンドラインから打ち込むのは大変なので、必要なオプションを記載したシェルスクリプトを用意して、作成時にはそのスクリプトを使うようにしています。

今回は、そのシェルスクリプトにバージョン番号と日付けを書き出すような処理を追加して、開発過程でどれくらいDVDイメージを更新するかを記録してみました。その結果は以下のようになりました。

この表からPlamo64の開発リズムが見えてくるでしょう。

最初のバージョン（0.1）と0.2の間が1月半ほど空いているのは、新しい開発環境がメンテナの間に広まり、その上でパッケージができてくるのを待っていたためです。

0.2と0.3の間は10日間ほどなのに対し、0.3と0.4の間は3ヵ月以上空いてしまっています。この0.3と0.4の空白期間は、筆者が非常勤講師の方の仕事に時間を取られてしまって、Plamoの開発に時間を割けなかった時期にあたります。

その後、7月は0.4, 0.5, 0.6の3度、8月は0.7, 0.8の2度と比較的落ちついたペースで更新していますが、9月ごろからペースがあがり出し、9月には0.9から0.16までの7度、10月には0.17から0.21までの5度、11月には0.22から0.28までの7度と、2週に3度くらいのペースでDVDイメージをバージョンアップしています。

もっとも、これらバージョン全てを実機にインストールしたわけではありません。たいていのバージョンはVirtualBox上の仮想マシン用で、DVDイメージのまま仮想マシンにインストールし、問題が見つかれば修正して、バージョン番号を更新して再テストする、こういう作業を繰り返した結果、これだけバージョンの履歴が増えてしまったわけで、同じ日や連続した数日の間にバージョンがいくつも上っているのもそのためです。DVD-R等に焼いて、実機にインストールしたのはこの1／3ほど、FTPサイトでテスト用に公開したのは、さらにその半分くらいだったように思います。

Change.Logの記述を見ると、本連載の26回目にも紹介したように、8月ごろまでにはgrub2やBtrfsなど、Plamo64で新しく採用した機能もほぼ動くようになってきました。一方、64ビット化を始めたころから一年近くが経ってしまったため、初期にビルドしたパッケージ類の中にはバージョンが古くなっているものも出てきました。

9月ごろからそれら古くなったパッケージの再ビルドサイクルが始まり、32ビット/64ビット両用になっていたパッケージを64ビット専用に再ビルドしたり、廃止されることになったHAL機能を使わないように再ビルドする作業が必要となりました。

特にHALに付いては、KDE-4.4.5が周辺機器の認識にHALを利用していたため、HALを廃止するためにはKDE-4.7にまで更新することが必要となり、Qtあたりからビルドし直すのに半月くらいかかった記憶があります。

最後の難関

その後、11月ごろからまとめの段階に入りましたが、何度もインストールしていると、Plamo-4.73までに用いていたパッケージのカテゴリ分けに問題があることに気づきました。

具体的に言うと、Plamo-4.73で用いていたカテゴリ分けでは、GtkやQtが普及する以前に開発されたX用のソフトウェア、たとえばAfterstepやQvwmといったウィンドウマネージャが、X Window Systemを構成するソフトウェアを収めている02_x11カテゴリに入っていました。その結果、XfceやKDEといった最近の統合デスクトップ環境では、それら旧世代のソフトウェアを使う必要が無いにもかかわらず、AferstepやQvwmもX環境の一部としてインストールされてしまっていました。

この問題は従来のPlamo-4.73等の環境でも起きていたわけですが、AfterstepやQvwmがウィンドウマネージャとして活躍していた時代に開発が始まったx86環境では、Xの必須の部品としてこれらのソフトウェアが存在することが当然のように思い込んでいたため、特に気にはなりませんでした。

一方、先にXfceやKDEといった統合デスクトップ環境が動作するようになったPlamo64では、開発が終了して久しいこれら旧世代のソフトウェアを、わざわざ64ビット用にビルドし直してまで追加することが無駄のように感じました。

そこで、これら旧世代のソフトウェアはcontribディレクトリに移動して、自動インストールの対象に含めないようにした方がいいのでは、とメンテナMLで提案してみたのですが、メンテナの人たちからはこれらのソフトウェアを支持する声が強く聞かれました。

そのため、折衷的な案として、これら旧世代のソフトウェアを新しいカテゴリにまとめ直し、X Window SystemやXfce、KDEとは独立にインストールの有無を選択できるようにしてみました。その結果、Plamo64ではインストール時に選択できるのは以下の10のカテゴリになりました。

このようにすることで、たとえばKDE環境の場合は00_base, 01_minimum, 02_x11, 05_ext, 07_kdeの5つのカテゴリを選択すれば、AfterstepやQvwm等をインストールしなくても動作可能になります。加えて、04_xappsをインストールすれば、firefoxやgimpといったKDEプロジェクト以外の便利なツールも使えるようになります。

一方、従来のウィンドウマネージャ環境の軽快さを好む人は 00_base, 01_minimum, 02_x11, 03_xclassics の4つのカテゴリを選択すれば、10年くらい前のGUI環境が構築でき、04_xappsを追加すればXfceやKDEをインストールしなくても最近の便利なソフトウェアを使うことができます。

カテゴリの再構成は、パッケージの移動だけではなくインストーラの対応も必要となるかなり大がかりな修正になりましたが、11月の下旬にほぼ変更を終えました。

その後は細部の調整をしつつ、新しいバージョンが出ているソフトウェアを随時更新しながら、12/15にRC1、12/27にRC2を公開し、RC2から3つほどパッケージを更新したバージョンをPlamo64-1.0ということにしました。

Plamo64からPlamo-5.0へ

以上のような過程を経て、x86-64用のPlamo LinuxであるPlamo64-1.0は12/31に正式リリースできました。しかし、これはx86とx86-64の両アーキテクチャに対応しようとしているPlamo-5.0の半分に過ぎず、x86用の環境を構築する作業が残っています。

ありがたいことに、筆者がx86-64に集中していた間もx86用のパッケージを更新し続けてくれたメンテナがいて、x86用の開発環境は既にx86-64と同等になっており、ビルドスクリプトのarch部をi586にするだけで、たいていのパッケージは再ビルドできそうです。

あまりグズグズしていると、既存のパッケージのバージョンが古くなって、バージョンアップの追いかけっこが始まってしまうので、x86用のパッケージはここ数ヵ月のうちに揃えてしまいたいと考えています。