過去2回に渡ってソフトウェアのトラブル対策の話題を取りあげましたが，それらを何とか乗り越えて，無事Plamo Linuxの新版である4.7を10月の初めにリリースすることができました。そこで今回は，Plamo Linuxがらみの話をしてみましょう。

Plamo Linuxについて

本連載を読まれている方はご存じのことと思いますが，Plamo Linuxとは，私がとりまとめ役になって開発を続けているLinuxディストリビューションです。

Plamo Linuxのきっかけは，当時のメジャー・ディストリビューションだったSlackware Linuxを使いやすくするために，インストーラを日本語化しようとしたことでした。その後，インストーラだけでなく，パッケージもあらかじめ日本語に対応したものに入れ替えるために，Slackwareから独立して独自の道を歩むことになりました。

公開当初は，インストール直後から日本語が使えるディストリビューションとしてそれなりに使われたものの，より進んだパッケージ管理システムと大規模な開発者リソースを持ったRed Hat LinuxやDebian GNU/Linuxが普及し，それらの国際化が進んで日本語も問題なく使えるようになるにつれて，Plamo Linuxの影は薄くなってきました。

最近はソフトウェアの大規模化，高機能化が進み，複雑な設定や絡みあった依存性に閉口することも多いのですが，昔から使い続けてくれるユーザもいますし，協力を惜しまないメンテナの方々もいます。何よりも，自分にとって手になじんだ環境を守りつつ最近の便利なソフトウェアも使いたい，そういうわがままからコツコツと続けているうちに，いつの間にか10年以上の月日が経ってしまいました。

ちなみに，Plamo Linuxのリリース歴はメンテナの一人でもある加藤さんが@niftyのTimeLineとしてまとめてくれているので，興味ある方はご覧ください。下図はそのうちのここ2年ほどの部分です。

Plamo Linux 4.7

Plamo Linux 4.7は，今年の2月ごろに公開した4.6の次にあたる公式リリース版です。GCCやglibc2といった主要パーツがバージョンアップしているため，バージョン番号は4.61ではなく4.7としましたが，含まれているパッケージ類は4.6と大きく変わらず，やや見切り発車的だった4.6の不具合を修正した，かなり扱いやすいバージョンになっていると思います。

GNOME環境では，本連載でも取りあげたfile-rollerアーカイバと共に，gThumb画像ビューワがEUC-JPな日本語ファイル名を正しく扱えない問題にも対処しましたし，KDE環境は，新しくメンテナにご参加いただいた本多さんの御尽力で，ライブラリレベルでの文字コードの扱いがずいぶん改善し，4.6ではしばしば発生していたEUC-JPなファイル名の文字化けがほとんど見られなくなりました。

先に紹介したタイムラインを見ても，2007／10に公開された4.22から，インストーラやパッケージ構成に大きな変更を加えた4.5までは1年ほど空きましたが，その後は約半年ぐらいの間隔で4.6, 4.7と進むことができました。

一方，4.7公開後にXのサーバをxorg-server-1.6系に更新したり，KDEも4.3.2に更新されるなど，すでに開発版にはかなり大きな更新が入っているので，そう遠くないうちにメンテナンスリリースを出す必要がありそうです。OSSの開発が盛んになるのはいいことですが，それらに追従し続けるのはなかなか大変です。

パッケージ形式とビルドシステム

Plamoの新版の宣伝だけでは「玩式草子」のネタにならないので，今回はPlamo Linuxの裏方であるビルドシステムについて紹介してみます。その前に少しLinuxの代表的なパッケージ形式について復習しておきましょう。

TGZ形式

Slackware/Plamo Linuxが採用しているパッケージ形式で，インストールしたいファイルを適切なディレクトリ構造に配置した上でtarコマンドで固め，それをgzipで圧縮した形式です。

この形式はLinuxの基本コマンドであるtarとgzipさえあれば操作できるので作成も展開も容易ですが，元々バイナリパッケージ配布用に考えられた形式ではないので，ライブラリやコマンドの依存関係をチェックしたりインストール情報を保存するような機能はありません。そのためSlackwareではinstallpkg/removepkgという専用のツールを用意して，installpkgでインストールしたパッケージの情報を/var/log/packages/ディレクトリに保存し，removepkgでこの情報を元にインストールしたファイルを削除するようになっています。

これらのツールはPlamo Linuxでもそのまま流用しています。

RPM形式

元々はRed Hat社が考案したパッケージ形式（Redhat Package Manager）でしたが，後に仕様を公開し，誰でも自由に使えるようにしたため，最近のLinuxでは最も広く用いられているパッケージ形式です。

RPMはTGZ形式の問題点を十分検討した上で考案されたパッケージ形式で，インストールするファイルはtarではなくCPIO形式でまとめて圧縮されており，パッケージの先頭部にライブラリやコマンドの依存関係など，管理に必要な情報が付加されています。そのため，RPM形式のファイルを操作するには専用のコマンド（rpm）が必要になります。なお，ヘッダ部分の管理情報を剥いてしまえばcpioコマンドでファイルを取り出すことも可能です。

RPM形式では，1つのパッケージ内に管理に必要な情報を全て盛りこんであるので，rpmファイルはシステムに関する暗黙の前提なしに，完結したパッケージとして利用できるようになっています。一方，そのような情報をきちんと盛り込むためには専用のSPECファイルが必要で，SPECファイルを書くにはそれなりの知識と経験が必要になります。

DEB形式

元々Debian GNU/Linuxで考案されたパッケージ形式で，インストールすべきバイナリファイルをまとめたtar.gzファイル（data.tar.gz）と，管理情報等をまとめたファイル（control.tar.gz）をarで固めた形式になっています。

DEB形式のパッケージも，本来はdpkg等の専用コマンドを利用して操作することを前提に作成されていますが，それら専用コマンドが無い環境でも，基本コマンドであるtarとgzipとarがあれば展開できるように設計されているのは思慮深いところです。

DEB形式のパッケージを作るためには，標準のMakefile以外にさまざまな設定ファイルが必要です。作業のかなりの部分はdh_makeコマンド等で自動化されるものの，Debian独自のルールに十分精通している必要があります。

上述のように，元々ソースコードを配布するために利用されていたTGZ形式は，パッケージを作るために特別な知識は必要ないものの，パッケージ管理に必要な機能を持たないため，それらを外部から補ってやる必要があります。補うのはツールであったり，ユーザの知識だったりします。

一方，最初からパッケージ配布用に考案されたRPMやDEBの形式は，単独のパッケージ内に管理に必要な情報を持つものの，パッケージの作成にはそれぞれ個別の知識が必要になります。

RPMやDEB形式ではパッケージの形式だけでなく，それらのパッケージを作るための手法も提供しています。たとえば，RPM形式ならばパッケージを作成するためにはSPECファイルが必要となります。このSPECファイルには，ソースコードの在所やパッチファイルとその当て方，必要なライブラリとそのバージョン，コンパイル時のオプションなどの情報を記載することができ，一度完成してしまえば設定を調整してコンパイルし直すのにも便利ですし，SPECファイルを使えば誰でもメンテナと同じ設定でパッケージを作成し直すこともできます。

Plamoの場合，元々のSlackware同様，TGZ形式を採用していますが，RPMやDEBの高機能に魅かれて手習いでいくつかSPECファイルを書いてみたこともあります。しかし，実際にSPECファイルを書いてみると，書かねばならないことが結構あって大変で，開発者リソースが豊富な大手ディストリビューションならばともかく，Plamoの規模ではとても対応できそうにありません。