Slackware 12.1：入手する価値あるアップグレード
このSlackware 12.1では、KDE 3.5.9やXfce 4.4.2といった新バージョンが採用されていると同時にudevなどについても多数の改善が施されているが、アップデート内容の詳細は同プロジェクトによるリリースアナウンスを参照して頂きたい。このような変更を施されたバージョン12.1をユーザ側の観点からまとめると、前バージョンをごく真っ当に改善した正常進化版と評していいはずだ。
Slackwareは現存する中でも最古参のLinuxディストリビューションであり、その初回リリースは1993年にまで遡ることができる。また同時にこれは“手作り”的な色合いが非常に強いディストリビューションでもあって、システム設定の大部分についてはユーザがテキストファイルを直接編集することで対処しなければならない。更にSlackwareは極めてプレインな構成のディストリビューションであることでも知られている。つまりこうしたSlackwareの開発に携わっているチームの嗜好としては、ソースに対する変更を最小限に留めた上で、そのコンパイル結果を提供するという方式が好みのようなのだ。
Slackware開発チームの設計思想は、パッケージ管理の方式に如実に反映されている。確かにSlackwareのパッケージ管理機能はコマンドラインおよびGUI（ncursesベース）の双方にて実行できるのだが、Slackwareの利用するパッケージ群と依存関係にあるライブラリの存在はチェックされないし、パッケージ管理用のツール群も別途必要なもののダウンロードやインストールを自動的に処理したりはしないのだ。つまりSlackwareを使用する場合は、こうした仕様であることを念頭に置いておかなくてはならない。また依存関係のインストールとアプリケーションのインストールとを異なるプロセスとしておくことは、依存性にまつわる問題が発生した場合も、このプロセスに起因して状況が複雑化しないことを意味する。それ以前に、Slackwareのフルインストールでは必要となるライブラリの選択肢がすべて提示されるようになっているので、確保すべき依存関係の大半はその時点ですべて入手できるはずなのだ。仮にここで提示されないものが存在したとしても、通常は必要なパッケージのダウンロードとコンパイルをしてインストールをするだけであり、Slackware用パッケージのコンパイル作業についてもSlackbuilds.orgから入手できるslackbuildスクリプトなどのツール群やscr2pkgを使用することで簡単化できるようになっている。
本ディストリビューションのメンテナを務めるVolkerding氏は保守派のようで、目新しい機能はある程度熟成するまでSlackwareでは採用しないという傾向が見られる。例えばSlackware 11のリリース時には2.6カーネルが利用可能となっており、他のディストリビューションではそれ以前に2.6カーネルへの移行が行われていたにもかかわらず、同バージョンのデフォルトインストレーションで選択されるのは2.4シリーズのカーネルであったくらいだ。また最近の事例においても、今回のSlackware 12.1ではKDE 4.0ではなくKDE 3.5.9が使われているが、Debian、Fedora、Kubuntu、openSUSEなどは既にKDE 4.0対応のパッケージをリリースしているのである。いずれにせよSlackwareが手堅い安定したディストリビューションとなっているのは、こうした保守的なアプローチが採用されているおかげと言っていいだろう。実際、設定さえ適切に行われていれば、Slackwareはトラブルフリーで運用できるはずである。システムのメンテナンスに要する負担は最小限で済み、それ以外に必要なのはセキュリティアップデートをリリースされるごとに適用することくらいでしかない。なお現状でのセキュリティアップデートは、Slackwareのバージョン8にまで遡る分が入手できる。
Slackware 12.1では、過去のバージョンにて取り込まれていた機能に対するブラッシュアップも施されている。例えばデフォルトインストレーションではHAL、D-Bus、udevが使用されるようになっているが、これらはリムーバブルメディアなどのデバイスをオペレーティングシステムと通信させたり挿入時の自動マウントを行うためのテクノロジである。今ではデスクトップ用オペレーティングシステムがこうした機能を装備していても当然だと大部分のユーザは思うようになっているが、Slackwareの場合も正しくセットアップされていれば、初心者ユーザであってもそうした処理を簡単に実行できるようになっているのだ。
Slackware 12.1で行われた改善はその表面下にて施されたものが大半を占めており、例えばPythonやRubyは最新バージョンが取り込まれているし、X11システムなども最新モジュールに置き換えられている。またSlackware 12.1でインストールされるglibc 2.7は既存バイナリに対する高度な互換性が確保されているので、Slackware 12で使用されていたアプリケーションの多くについては、ユーザが再コンパイルする必要はないはずだ。実際に私もSlackware 12にてコンパイルしたアプリケーションを用いて、Slackware 12.1における下位互換性の高さを確認している。その他の旧バージョンからの顕著な改善点としてはX Window Systemの動作が著しく高速化された点があり、私のように旧式化したハードウェア環境にて利用するユーザにとって、こうした機能向上は特に重要な意味を有しているのである。
アップグレードの対象と事前の準備
私の場合バージョン12.1へのアップグレードは、2台のコンピュータにて実行している。その1つは2006年後半からSlackware 11を使い続けてきたデスクトップコンピュータで、もう1つは昨年12月からSlackware 12を使ってきたラップトップコンピュータである。これら2つのコンピュータにおけるSlackware 12.1の導入はどちらも“アップグレード”であることに間違いないはずなのだが、実際には各コンピュータごとにかなり異なる操作を強いられることになった。このうちバージョン12から12.1への移行はごく素直なアップグレードであって、新規のカーネル、ツールチェーン、ソフトウェアをインストールして、既存のソフトウェア群をアップグレードするだけである。それに対してバージョン11から12.1という場合は、ハードドライブに存在するSlackware 11インストレーションを削除してから、改めて新たなSlackware 12.1をインストールしなければならなかったのだ。
なお、いずれのケースにおいてもバージョン12.1のインストール前には、若干の事前準備が必要となる。
- ドキュメント類の記載内容を確認しておく。Slackwareのインストール用CDセットないしDVDには、テキストファイル形態で多数の情報が同梱されている。いずれも重要な情報であるため、事前にこれらに目を通しておくことで、後々発生しうる多くのトラブルを未然に予防できるはずである
- SlackwareのオフィシャルサポートフォーラムであるLinux Questions WebサイトのSlackwareフォーラムにて関連情報を収集しておく。ドキュメント類に記載された情報だけでは不明な事項が残される場合もあるが、Slackwareの開発者を含むベテランユーザが集まっているフォーラムに疑問を投稿すれば、親切な人間が問題を解決するための助言をしてくれる場合がある。また自分と同じ疑問を抱いたユーザが以前にいれば、そのソリューションは過去ログの中に残されている可能性が高い
- /etcディレクトリをバックアップしておく。私の場合このデータは、1つの.tarファイルにまとめた上で、再フォーマットをする予定のないドライブのパーティションに移動しておいた。その他必要に応じて各自の/homeおよび/rootディレクトリもバックアップしておく
以上の準備が済めば、実際のインストールに進むことができる。
Slackwareのアップグレード手順
ここでは私の行ったアップグレード操作における個々の手順を逐一書き下すことはせず、重要なポイントおよび私の遭遇したトラブルについての説明のみをすることにする。
先に述べた2種類のインストール作業のうち、おそらくはクリーンなインストールの方が簡単だと思われるだろうが、実際はその逆になってしまった。ここで言う“クリーンなインストール”とは、必要なファイル群をすべて真っさらな状態でインストールした後に、バックアップしておいたデータや設定の復元作業を新規のインストレーション上にて行う手順だと考えておけばいいだろう。ところが私の場合、こうした一見シンプルなプロセスを満足行く結果にもっていく手順を確立するまでには、インストールプロセスを何度か試行錯誤的に繰り返さなければならなかったのだ。その過程で遭遇したトラブルの1つは、非特権ユーザのアカウントを再現する際の問題というものである。最初私は既存の/homeディレクトリ群をそのまま利用しようとしたのだが、新規に作成した各ユーザのhomeディレクトリをこれらのディレクトリにポイントさせようとしたところ、ユーザIDに不整合が生じてしまったのだ。結局これらについてはゼロから作り直し、バックアップしておいた設定ファイル群（FirefoxおよびThunderbirdのプロファイルなど）を新規のディレクトリにコピーするしかなかった。ただし今から考え直すと、バックアップしておいた/etcディレクトリからgroup、passwd、shadowの各ファイルをコピーし直せばよかったはずで、こうした措置によりおそらくは既存のhomeディレクトリを使い回した形で問題なくログインできていたものと思われる。
Slackware 11から12.1へのアップグレードに関しては、その他にも2つのマイナーなトラブルに遭遇している。1つ目のトラブルは、xorgsetupおよびxorgconfigユーティリティの作成するxorg.confに関する問題である。この件についてはバックアップしておいたSlackware 11のxorg.confで新規のファイルを置き換えるという対策をしたところ、すべては正常に動作するようになってくれた。2つ目のトラブルは、ある特定ハードウェアとHALとの互換性に関係した問題のようで、具体的には私が7年間使用してきたHewlett-PackardのCD-Rドライブが勝手にCDを排出してしまうという現象である。この問題についてはUbuntuフォーラムの関連情報を確認したところ、これは旧式ドライブにて発生する現象らしきことが分かったのだが、有望な回避策として判明したのは、このドライブをfstabファイルに追加しておき、使用時には手作業でマウントするというものであった。なおトラブルを起こした同じコンピュータであっても、世代的により新しいDVDドライブでこの問題は発生していない。
最後に行わなければならなかったのは、OpenOffice.org、Frozen Bubble、Kaffeine、Scribus、MPlayerなど、Slackwareに同梱されていないアプリケーション群のダウンロードとインストールである。もっともこの作業に関しては、Pentium IIIで駆動する私の骨董品マシンであっても、それほどの時間はかからなかった。
こうしたクリーンなインストールに比べ、Slackware 12から12.1へのアップグレードでは問題らしき問題はほとんど発生していない。このプロセスで必要となるすべての手順についてはUPGRADE.TXTファイルに簡潔にまとめられている。ただし私の場合は必要なデータをバックアップした後、3枚構成のインストール用CDにある/slackwareディレクトリの収録ファイル群を自分の/rootディレクトリにコピーするようにしたが、これは新規パッケージのインストールをCD群からではなくハードドライブから行うようにさせるためである。その後の操作はインストール手順の指示書どおり実行することで問題なく進行しており、既存パッケージの新バージョンへのアップデートおよび完全な新規パッケージ群のインストールもupdatepkgプログラムが正常に処理してくれた。なお新規の設定ファイルについては“.new”という拡張子が付けられるようになっている。UPGRADE.TXTファイルには、こうした.newファイル群をインストールして古いファイル群の拡張子を“.bak”に変更するためのスクリプトが用意されているが、group、shadow、passwdファイルはこのスクリプトで変更されることはない。最後の仕上げとして行うべき操作は、startupファイルにアップデートを施す（初期RAMディスクのポイント先を新規カーネルに変更してlilo.confへのアップデートを行う）、バックアップしておいたその他の.confファイル（6個程度）の内容を新規設定ファイルに反映させる、不要化したいくつかのパッケージを削除するというものである。その他、私の所有する無線カードが必要とするMadWifiはSlackwareには同梱されていないため、このパッケージについてはダウンロードとアップグレードをしなければならなかった。なお従来の設定を新規バージョンに反映させる作業については、トラブルフリーで実行できている。
まとめ
Slackware 12.1へのバージョンアップは、優れたディストリビューションを入手するための価値あるアップグレードと評せるもので、私個人としては大いに奨励したいところである。ただし本稿でも解説したように同ディストリビューションの構成は、ユーザ側の視点からするとある種の二面性を秘めている。つまりそのシステム設定はユーザフレンドリとは言い難い方式で行うしかないのだが、これを稼働させるために必要となる情報は各種ドキュメントの形できっちり整備されているし、設定ファイルのテキスト編集と言っても実際の手間はごく限られたものでしかないのである。こうした設定法については“簡単”と言うよりも“シンプルで分かりやすい”と表現するべきだろうか。いずれにせよ本稿で解説したような手間を掛けて得られるのは、強力であるにもかかわらずメンテナンスの負担がきわめて小さい近代的なLinuxシステムなのである。
Drew Amesは、ペンシルバニア州ハリスバーグにてトランスポーテーションプランナとして活動している。
