Turbo Linux 10 F 上では、メーラーとして Sylpheed 1.0 を使用していました。Sylpheed は Windows 上で使用していた電信八号ともよく似たインターフェイスであり、重宝していました。
Sylpheed 1.0 は GTK1.0 で作成されていましたが、最近 GTK2.x 系への移行を進めており、1.9 系として GTK2 対応がはかられました。GTK2 対応により、TrueType フォントが利用可能となり、見た目的にも、Outlook Express と遜色ない出来となっていました。MS-DOS から Windows へ移行した最大の理由がフォントにあった私にとっては、GTK2 対応の Sylpheed は、まさに打ってつけ、といえました。
しかし、事はそんなに簡単ではありませんでした。Turbo Linux 10 F は、GTK 2.2 対応でしたが、Sylpheed 1.9 は GTK2.4 を要求しており、単純に tarball を持ってきてコンパイルすることはできません。GTK を更新するということは、glib も更新することになるわけですが、glib はシステムを支えている重要なライブラリであり、一つ間違えれば、システム起動不能に陥ってしまうこともあり得るため、そう安易に GTK を更新するというわけにもいきません。
Turbo Linux の ftp サイトを探してみたところ、運良く Turbo Linux 10 Server 用のパッケージ群が見つかりました。その中を見ると、GTK2.4 対応と思われるパッケージが見つかりました。念のため、Turbo Linux 10 Server Trial 版で確認したところ、Turbo Linux 10 Server は GTK2.4 対応となっていることが確認できました。ということは、この Turbo Linux 10 Server 用の GTK2.4 パッケージを持ち込むことで、GTK2.4 化可能となるのではないか、と考えたわけです。
GTK 2.4 化には、RPM パッケージを拾ってきていれれば良い、というわけには行きません。公式には、TL10F 用の GTK2.4 用パッケージが用意されているわけではないので、やってみないとうまく行くかどうかわかりません。といっても、先に進むしかないのが、実状ではありますが(苦笑)
まずはパッケージを入手することから始まりますが、ここでいきなり悩むことになります。Turbo Linux 10 Server は、kernel 2.6.8 ですが、Turbo Linux 10 F は kernel 2.6.0-21 と kernel からして異なります。となるとバイナリパッケージ(.rpm)をそのまま使うのは少々危険と感じます。そこで、ソースパッケージ(.src.rpm)を持ってきて、自前でコンパイルすれば、確実に動作するはず、ということにたどり着きました。
GTK2.4 の環境を整えるために必要となったソースパッケージは下記の通りです。
パッケージが入手できたところで、早速コンパイルすることになりますが、ここに一つの落とし穴が待っています。何かというと、依存関係の問題です。あるパッケージをコンパイルするためには、別のパッケージがインストールされていなければならない、ということを依存関係とよびますが、上記のパッケージはまさに依存関係が激しく、上から順にコンパイル→インストールを繰り返していく必要があります。上記の順番は、依存関係をクリアしながら、インストールを進める順番ともなっています。
入手したパッケージをコンパイルするわけですが、.src.rpm の コンパイルは、rpm コマンドに、rebuild スイッチをつけて、
rpm -rebuild パッケージ
で行います。なお、TL10F では、rpm コマンドは root ユーザーで行うようになっているようで、一般ユーザーで rpm -rebuild を実行してもエラーとなります。rebuild に成功すると、作成されたバイナリパッケージ(.rpm) が /var/src/rpm/RPMS/i586/ に保存されています（rebuild 中のメッセージを見ていると、作成されたパッケージが書き込まれていることが確認できます。） 上記の４パッケージは、devel が付いているものと付いていないものの二つのパッケージが作成されます。devel は開発環境として必要なのですが、依存関係にあるパッケージを rebuild する際に必要となるため、作成されたパッケージは両者ともインストールしなければなりません。rpm コマンドでインストールを行う時は、ivh スイッチを使います。しかし、今回導入するパッケージは、TL10F 標準のものはすでに導入されているため、更新処理を行うことになります。この更新処理は Uvh コマンドで行います。
例1 glib2-2.4.6.src.rpm をコンパイル
#rpm -rebuild glib2-2.4.6.src.rpm
例2 glib2-2.4.6.i586.rpm と glib2-devel-2.4.6.i586.rpm を インストール
#rpm -Uvh /var/src/rpm/RPMS/i586/glib2-2.4.6.i586.rpm /var/src/rpm/RPMS/i586/glib2-devel-2.4.6.i586.rpm
別々にインストールしようとしても、パッケージ間に依存関係があるので、一括でインストールしなければなりません。
このようにして、すべてのパッケージを更新すると、無事 GTK2.4 環境が構築できました。
Sylpheed は、tarball で配布されているため、make が必要と考えてしまいますが、実は SPEC ファイルが同梱されており、src.rpm 同様に、rpm コマンドでコンパイルが可能です。ただし、tarball からのコンパイルには、-rebuild ではなく、tb スイッチを使います。
例3 Sylpheed 2.0beta1 をコンパイル
#rpm -tb sylpheed-2.0.0beta1.tar.gz
パッケージが出力されるところは、rebuild と同一です。ところが、ここでエラーが発生します。libtiff のバージョンが低いといわれるので、新たに libtiff-3.6.1.src.rpm を入手してコンパイル＆インストールすると、Sylpheed のコンパイルがスムーズに行われます。
できたパッケージを Uvh でインストールするわけですが、TL10F のパッケージに対し、Uvh で本当に大丈夫か、不安がのこりました。そこで、念のため TL10F の Sylpheed をアンインストールして、改めてインストールすることにしました。
例4 TL10F の Sylpheed を削除
#rpm -e sylpheed
例5 Sylpheed 2.0.0beta1 をインストール
#rpm -ivh /var/src/rpm/RPMS/i586/sylpheed-2.0.0beta1.i586.rpm
ところが、ここでエラーが返ってきてしまいました。コンパイルが完了している以上、動作する環境はそろっているはずなのになぜ、と悩みました。
gtk+ >= 2.4.0 is needed by sylpheed-2.0.0beta1-1
GTK2.4 環境は用意できたので、コンパイルできたのではないの？と思い、掲示板に質問をあげてみたところ、心優しい方からコメントをいただきました。
SPEC ファイルに記載されているパッケージ名と TurboLinux のパッケージ名が異なっているためでは？
いただいた助言から、SPEC ファイルを書き換えることで対応できそうだという判断ができました。そこで、一度 Sylpheed のパッケージをばらして、SPEC ファイルを修正後、再度 tarball にまとめ直す、という方法をとりました。
例6 tarball の展開
$tar zxvf sylpheed-2.0.0beta1.tar.gz
例7 tarball の作成(作成する書庫ファイル名を先に指定します。)
$tar czvf sylpheed-2.0.0beta1.tar.gz sylpheed-2.0.0beta1
再び rpm -tb でコンパイルし直したところ、無事インストールが完了しました。
GTK2.4 化した TL10F ですが、問題がないわけではありません。少なくとも、今後の更新パッケージが出てきた際に、GTK 関係が最新パッケージとして認識されるかどうか、慎重にみていく必要があります。一応は rpm コマンドでインストールしているので、パッケージ更新時には確認されるのではないか、と考えていますが、どうなるかは予断を許しません。また、kernel については、想定されている環境と異なることから、手動で再構築する必要さえ出てきます。
とはいえ、GTK 2.4 を要求するアプリケーションが増えてきていることは、現実問題として存在しています。いかに優れたツールであっても、対象とする OS 上で使えなければ、意味がないわけですから、この更新は、現時点では、最良の方法であったと考えています。
しかし、TL10F 以来、メインストリームを受け持つ製品の話が出てこないことが不安です。TL10F から収録パッケージを削って、basic よりも小さくなった製品を 1,980円で出す、という話も聞こえてきます。たしかに、価格を下げることは、消費者にとってのアピールになりますが、反面、製品の価値を下げることにもなり、信頼性という点では不安に感じるユーザーも出てくるのではないか、と感じられます。はたしてどうなるか、予断は許さない状態と言えます
Last Update is 2005/07/11. CopyRights Tazoe Kazuya 2005.