Slackwareに対応した各種のパッケージ管理ユーティリティ
Slackwareのパッケージはgzip圧縮されたごく単純なtarボール形式で配布されており、そのファイル名についてもphp-5.1.6-i486-2.tgzのように「名称-バージョン-アーキテクチャ-リビジョン.tgz」という形式で統一されている。このtarボールを展開してファイルを抽出するにはtar -xvf php-5.1.6-i486-2.tgzというコマンドを実行すればよく、これにより、etc、usr、installという3つのディレクトリが作成される。installディレクトリにはdo-inst.shというスクリプトが格納されているはずだが、その役割は、同時に展開されたetcおよびusrディレクトリ中のファイルがSlackwareによってrootディレクトリ下にある/etcおよび/usrディレクトリに統合される際のサポートをするものだと考えておけばいい。
ここまでの説明を聞く限り、Slackwareのインストールは簡単で誰でもできると感じるかもしれないが、実際はそうではないのである。確かに、スタンドアローン型のアプリケーションをインストールするだけなら特に問題はない。ところが同じアプリケーションのインストールでも、他のプログラムやライブラリとの依存関係にあるものを扱う場合、Slackwareのパッケージ管理ツールはその融通の利かなさ加減を遺憾なく発揮してしまうのだ。
リポジトリベースのソリューションとして作成されたDebianのapt-getやFedoraのyumなどのパッケージとは異なり、そもそもSlackwareパッケージは、プログラム間の依存関係を認識するように設計されていないのであるが、Slackwareのハードコアユーザとなると、それで特に不自由を感じないものなのだ。実際、依存関係はユーザが手作業で管理するというSlackware流の方式にも、それなりのメリットが存在している。その1つは、システムにインストールされたプログラムやライブラリのすべてを管理者が把握できるという点だ。
そしてこの現役最古参のディストリビューションには、歴史が長いが故の長所も存在している。例えば、熱烈な開発者たちにサポートし続けられているSlackwareのパッケージ管理ツール群は、他の追随を許さないくらいに充実していると言っていいだろう。ここでは、そのいくつかを紹介することにする。
由緒あるパッケージツール群
Slackwareでは様々なパッケージ管理ツールが利用できるが、これらの中にはディストリビューション本体の出現当時から使われているものも存在する。その代表選手といえば、ncurses形式のメニューインタフェースを備えたpkgtoolユーティリティであろう。このツールの特長は、カレントディレクトリ以外の場所からでもパッケージをインストールできることである。またこのツールは、過去にインストールされたすべてのアプリケーションを認識することができ、そうした複数のアプリケーションを一度に削除することもできる。その他、各アプリケーションの簡単な説明を表示させたり、インストール済みアプリケーションに関連するファイルの一覧を確認するといった操作も行える。
Slackwareパッケージの、インストール、削除、アップグレードを行えるツールは、先のpkgtoolだけという訳ではない。例えば、installpkg、removepkg、upgradepkgというツールは、引数に指定されたアプリケーションのインストール、削除、アップグレードを行うためのユーティリティである。
またinstallpkgおよびremovepkgコマンドでは-warnというオプションを指定することもできる。このオプションを指定してこれらのコマンドを実行した場合、アプリケーションを実際にインストールするのではなく、特定のパッケージをインストールさせた場合に上書きないし削除されるファイルやディレクトリの一覧が出力される。
また、パッケージのインストールでどのようなファイルが追加されるのかを事前に確認しておきたいというケースもあるだろう。その様な場合は、explodepkgコマンドを用いてtarボールをカレントディレクトリに展開し、そこに表示されるファイル群を調べてみればいい。
Slackware用でない他のパッケージからのインストール
Slackwareというディストリビューションは長い歴史を有しているにもかかわらず、Slackware用パッケージの提供をしているアプリケーション開発者の数は、実はそれほど多くはないのである。そのため必要なパッケージのSlackware版が用意されていないこともあり、そうした場合に取りうる選択肢としては、ソースからアプリケーションをコンパイルするか、あるいは、利用可能であれば相当するRPMパッケージを使うか、という2つの方法が考えられる。後者の場合、RPMパッケージをあらかじめSlackwareパッケージのフォーマットに変換しておかなければならない。そうした処理にはrpm2targzおよびrpm2tgzというツールを使えばいい。私の経験で言うと、Joe Text Editorなどの単純なアプリケーションのRPMパッケージをtgz形式に変換してからインストールおよび削除したことが何度かあるが、特に問題に遭遇したことはなかった。
アプリケーションをソースからインストールする場合はCheckInstallというツールを使うことになるが、このツール自体はSlackware用のパッケージなので使用するための準備は簡単に行えるはずだ。ただしこの方式によるアプリケーションのインストールをする際には、当該アプリケーションの設定、コンパイル、インストールを行うために./configure、make、make installというコマンドの実行も必要となる。
CheckInstallが具体的にどう機能するかだが、このツールはmake installの実行直前に起動することで、新規にインストールするアプリケーションによって何がシステムに追加されるかを監視してゆくのである。そうした作業がすべて終了すると、最終的にSlackwareパッケージが作成されるという流れになる。CheckInstallの詳細については、以前に掲載された「CLI Magic」という連載記事の1つに解説してあるので、そちらを参照して頂きたい。
リポジトリベースのパッケージ管理ツール
先に紹介したpkgtoolユーティリティにおける最大の欠点は、ローカルのマシン上にあるパッケージしかインストールできないことである。そうした制限がわずらわしいと感じた場合はSlackpkgというツールの出番となる。Slackpkgには、パッケージのインストールやアップグレードをネットワーク経由で行う機能が装備されており、DebianのAPTと同様に、オンラインリポジトリにアクセスすることが前提となっている。このツールを実行すると、Slackwareのオフィシャルミラーサイトの1つからパッケージ情報の収集が行われる。ユーザはその情報を基に必要なパッケージを指定すればよく、その後のダウンロードおよびインストールは自動的に実行させることができる。
Slackpkgはデフォルトではインストールされないが、SlackwareのインストレーションCD-ROMの2枚目にあるextras/ディレクトリに収録されているので、installpkgを用いれば簡単にインストールできる。このツールを使用するには事前にミラーサイトの1つを指定しておく必要があるが、それには/etc/slackpkg/mirrorsファイルを編集し、用いるミラーサイトのアドレスに対するコメントアウトを解除しておけばいい。
ミラーサイトの指定が終わったらslackpkg updateコマンドを実行して、パッケージの認証に必要となるGPGキーなどの関連情報を収めたファイル群をミラーサイトからダウンロードしておく。ツール本体に対するアップデート処理が完了すれば、Slackpkgによるパッケージ管理が行えるようになる。例えばSlackpkgを用いてオンラインリポジトリから何らかのパッケージを取得すると、バックグラウンドでinstallpkgが起動して必要なインストール処理が実行されるし、パッケージの削除およびアップデートをする場合も同様に、removepkgおよびupgradepkgツールが自動的に実行される。
近代的なディストリビューションであれば、ネットワーク経由によるインストールとアップデートに対応しているものだが、Slackwareの場合もSlackpkgツールを用いることで、こうしたディストリビューションに引けを取らなくなると言っていいだろう。ただしこのツールにも欠点はある。以前に掲載されたSlackware 11.0に対するレビュー記事でも触れておいたように、このツールの検索機能では本来返されるべき結果がヒットしない場合があるのだ。
依存関係の解決ツール
ここまでに紹介したツールは、いずれも依存関係を扱う機能が装備されていない。多くのデスクトップユーザにとって、これは見過ごしがたい不備だろう。だからと言って、これらのツールに不満をぶつけるのはお門違いというものである。先に言及しておいたように、そもそもSlackwareパッケージのフォーマット自体が依存関係を扱える設計になっていないからだ。こうした状況を受ける形で、Extended TGZという新世代のフォーマットがSlackwareユーザたちの手によって開発されている。この拡張版TGZフォーマットに収められるパッケージについては、その依存関係に関する情報も格納されるようになっているのである。
サードパーティ系のものになるがLinuxPackages.netおよびSlacky.itで管理されているSlackware用パッケージ群も依存関係に対応している。これらのリソースについてはコミュニティによる積極的なサポート活動が行われているので、関連サイトをあたれば、必要とするアプリケーションの多くについてその最新バージョンを見つけることができるだろう。
ただし依存関係の問題はこうしたパッケージ単体で解決されるものではなく、そうした事情はSlackware付属のpkgtoolやslackpkgについても同様である。そのために用意されているのがSwaretおよびSlapt-getというツールである。
swaretは、Slackwareパッケージの管理アプリケーションとして最も人気があるツールと言っていいだろう。先に紹介したSlackpkgと同様、このswaretもインターネット経由によるパッケージのインストールとアップグレードを行うためのツールであり、オフィシャルリポジトリからのパッケージ取得機能が装備されている。またswaretの場合、LinuxPackages.netなどのサードパーティ系リポジトリからのパッケージ取得にも対応しているのが特長だ。その他、アプリケーションの依存するライブラリ群の一部が存在していない場合も考えられるが、swaretではそうした欠落ライブラリをインストールすることも行える。
swaretを使うには、そのTGZファイルを取得してインストールを行い、サンプルの設定ファイルの名前を変更した上で/etc/swaret.confのパスに格納して、用いるミラーサイトおよびローカルのtgzファイルの保管場所などのオプション設定を変更しておく。なおupgradepkgツールによるアップグレードとは異なり、swaretの場合はアップグレードされる側のパッケージをバックアップしておき、後から古いバージョンにロールバックすることも可能である。またスクリプトを記述しておくことにより、Slackwareディストリビューションの新規バージョンがリリースされた際にswaretを用いたアップデートを自動的に実行させることもできる。
真の意味で依存関係の解決を行いたいのであれば、現状でslapt-getより優れたツールは存在しないだろう。このツールは複数のリポジトリに対応しているだけでなく、ライブラリおよびアプリケーション双方の依存関係に対処できるからだ。私個人としてもswaretよりslapt-getの方が気に入っているのだが、その理由としては、swaretにある機能のすべてを網羅していること、オプション構成がapt-getのものとよく似ていること、スクリプト制御に対応していることが挙げられる。なおslackpkgと同様、slapt-getによるパッケージの管理では、Slackware付属のパッケージ管理ツール群であるinstallpkg、removepkg、upgradepkgが必要となる。またslapt-getについては、その使用法に関する多数のドキュメントが用意されている。
Slackwareで使えるPortageライクなシステム
GentooというLinuxディストリビューションが他のディストリビューションと一線を画しているのは、Portageという独自のパッケージ管理システムが整備されている点である。Portageとは、Gentoo用パッケージの設定、コンパイル、インストールを行うemergeユーティリティが用いるビルドスクリプトのコレクションだと考えればいいだろう。そしてこのシステムには依存関係に対応する機構も取り込まれている。Slackwareの場合、こうしたPortageライクなシステムとして、EmerdeおよびPortpkgという2つのシステムが利用できる。
Emerdeとは、GentooのPortageツリーとの同期を行い、必要なビルドスクリプトをダウンロードして、Slackwareへのインストールを行うというシステムである。ただしEmerdeは未だベータ版段階にあり、パッケージ間のコンフリクトも懸念されるため、開発陣からは必要最小限なSlackwareインストレーション上で使用することが推奨されている。なおこのシステムは、Slackwareパッケージを直接インストールすることもできる。
SlackwareでPortageライクなシステムを運用する第2の選択肢がPortpkgである。Portpkgの場合は、Gentoo用のPortageではなく、Slackware固有のビルドファイルであるSlackBuildを使う点が異なっている。Portpkgはその設計段階からSlackware専用で使うことが意識されており、システムのアップデートについても、swaretおよびalong-sideを併用することでパッケージ間のコンフリクトを引き起こさないよう配慮されている。
これら2つのシステムを比較すると、新米ユーザにとっては、Slackware付属のinstallpkgツールと使用法が似ているPortpkgの方が使いやすいだろう。対するEmerdeは、オンラインリポジトリとの同期をする関係上、回線速度の低いインターネット環境で使うのは現実的ではないはずである。また一方で、Portpkgを使ってすべてのアプリケーションに対するビルドファイルを取得するというのも、現実的な選択肢ではないと言える。
まとめ
そもそもSlackwareというディストリビューションでは、自分の使用するシステムは隅から隅まで自らの手で管理しないと気が済まないというユーザが前提にされている。そうしたユーザはSlackwareのパッケージ管理システムに絶大な信頼を置いており、その他の選択肢など端から受け付けようとしないものである。逆に、近代的なディストリビューションに慣れ親しんで、クリック一発でインストールできるシステムが当然だと感じられるユーザにとっては、Slackwareに依存関係の対処機能がネイティブに装備されていない理由を納得することはできないであろう。
Slackwareにおいても依存関係を自動処理させることは不可能ではないが、そうした機能が使える最大の功績は、Slackwareの創設者にてメンテナ兼開発者を務めるPatrick Volkerding氏に帰すると言っていいはずだ。なぜならswaretやslapt-getなどのアプリケーションは、そうした機能を利用する形で成立しているからである。その一方で、EmerdeおよびPortpkgといった新世代のツールは、他のディストリビューション用のソースをベースとしたアプリケーションのインストールという方式が採用されている点で、古参ユーザと新米ユーザの双方を満足させる存在となるかもしれない。
