Slackwareとパッケージリポジトリのシームレスな統合を可能にするsbopkg

Drew Ames
シェア

　どのようなLinuxディストリビューションであれ、ユーザー全員の望みにかなうあらゆるパッケージを最初からバンドルすることは不可能であるため、多くのディストリビューションでは、ユーザー各自が必要とする追加アプリケーションを独自にダウンロードするためのソフトウェアリポジトリが用意されている。そしてSlackwareに関してはSlackBuilds.orgという非公式リポジトリも2006年から運営されており、これは非常に完成度の高いサイトなのだが、同リポジトリからのアプリケーション取得には手動操作による複数のステップが必要で、実際の利用にあたってはWebブラウザと仮想ターミナルとの間を何度も往復しなくてはならないのが難点と見なされてきた。本稿で紹介する sbopkg はこうした負担を軽減するべく、SlackBuilds.orgからユーザーが取得するパッケージを自動ビルドさせるために用意されたncursesベースのサポートユーティリティだが、それだけに止まらず、オペレーティングシステムとリポジトリとのシームレスな統合も図られているのである。

SlackBuilds.orgは非公式なサイトであるとはいえ、実質的にはSlackwareのオフィシャルリポジトリに限りなく近い存在となっている。その運営にあたっているスタッフはSlackware開発チームの人間であるし、Slackwareのリリースノートにおいても、メンテナの一員であるPatrick Volkerding氏による同サイトの使用を推奨する文章が記載されているのだ。そしてSlackBuilds.orgを用いたパッケージのビルド手順をスリム化するための自動処理ツールとして作成されたのが、ここで解説するsbopkgである。

　sbopkgの使用法をマスターするにあたっては、次に説明するSlackwareパッケージおよびSlackBuilds.orgの概要を把握しておかなくてはならない。

Slackwareパッケージの概要

　Slackwareの特長の1つは“ユーザーに対し透明性を保つ”という理念の下に構築されたLinuxディストリビューションであるとしていいだろう。そのため多くのSlackwareユーザーは、設定ファイルの手作業による編集やソフトウェアのソースからのコンパイルを始め、各自のシステム管理は自分自身でできて当然だという意識を持っているのだ。それでも第三者がコンパイルしたバイナリパッケージに関しては、その際に使用されたライブラリの種類やバージョンが手元のものと同じであるか、あるいはコンパイル時にオプションの変更がされていなかったかを窺い知ることはできない。

　Slackwareでもバイナリパッケージは利用可能だが、これらが関係するインストール済みアプリケーションのアップグレードや削除をパッケージ管理ツールが問題なく処理できるよう、その作成プロセスについては標準化された手続きを踏むよう定められている。そして、こうした制約下でのパッケージ作成プロセスを自動化するべくSlackware開発陣により整備されたツールがSlackBuildスクリプト群なのである。

　SlackBuildスクリプトの実態はシェルスクリプトの一種であり、通常これらはroot権限下で実行され、ビルド用の一時ディレクトリを自動的に用意し、同ディレクトリにてソフトウェアの設定とコンパイルとインストールをした上で、Slackwareのmakepkgユーティリティを用いたパッケージ作成を行うようになっている。こうして作られるSlackwareのパッケージはtarボールをgzip化したものだが、そのための正しい設定とコンパイル用オプションが確実に適用されるようにすることがSlackBuildスクリプト群の役割だと思っておけばいいだろう。同じくmakepkgの役割は、パッケージ関連のSlackwareユーティリティ群によるこれらファイルの“/”ディレクトリツリーへの解凍時に、必要なパーミッションが与えられた上で正しい場所に格納されるようにすることなのである。

　SlackBuilds.orgにて扱われているのはSlackBuildスクリプトだけでなく、「高度な水準を維持しつつSlackBuildスクリプトのコレクションを最大限に広げる」という目的の下、Slackwareの正式ディストリビューションには含まれていないアプリケーション用の補助ファイル群も提供されている。実際その品揃えは豊富で、OpenOffice.orgのような有名アプリケーションはもとより、各種パッケージにて使われる200以上のライブラリまでもが収録されているのだ。

　このサイトに付随する問題点は、使用法自身は簡単なのに、実際の操作終了までに結構な長時間を要する場合があることだ。確かにこのリポジトリはブラウジング形式の操作だけでなく特定パッケージの検索もできるようになっており、各パッケージにはそれぞれの専用ページおよびソースファイルのダウンロード用リンクが用意されていて（SlackBuilds.orgではなく各自のサイトにてホストされているもの）、SlackBuildスクリプト本体とパッケージ情報に関するテキストファイルを収録した圧縮ファイルには、インストール後に必要となるその他のスクリプト群が用意されている場合もあるくらい内容的には充実している。その一方でSlackBuildスクリプトを用いたパッケージビルドを行うにあたっては、以下の操作をしなくてはならないのだ。

  1. SlackBuildのアーカイブをダウンロードして専用のフォルダに展開する
  2. ソースファイルをダウンロードして先のものと同じフォルダに移動する
  3. SlackBuildスクリプトに対して必要な編集を施す
  4. rootユーザー権限にてSlackBuildスクリプトを実行する（通常このプロセスで作成されたパッケージは/tmpディレクトリに収められる）
  5. パッケージをインストールする

　こうしたプロセス自体は特別難しいものではないが、手作業による複数の操作を実行しなくてはならない。つまり、単に1回行うだけなら上記の手順によるパッケージのビルドなどは短時間で済む部類の作業ではあるのだが、依存関係にある多数のパッケージが複合化しているような場合は、それらをビルドする時間の積み重ねが馬鹿にならない量になってしまうのだ。

sbopkgにて行われる処理

　sbopkgの機能は、こうしたプロセスをスリム化して、パッケージ作成ステップを自動化することである。sbopkgを使用するには、配布用のWebサイトにあるダウンロードページからコンパイル済みのバイナリまたはソースファイルをダウンロードしておかなくてはならない。なおこのソースファイルには、sbopkg自身に対するSlackBuildスクリプトも含まれている。同パッケージをroot権限下にてインストールした後には/etc/sbopkg/sbopkg.conf.newファイルの編集をすることになるが、デフォルトで適用されるのは下記のオプション設定である。 

RSYNCMIRROR=slackbuilds.org::slackbuilds
SLACKVER=12.1
LOCALREPO=${LOCALREPO:-/home/sbo}
SRCDIR=${SRCDIR:-/var/cache/sbopkg}
export TMP=${TMP:-/tmp/SBo}
KEEPLOG=YES
TERMBUILD=NO

# Optional - the $OUTPUT variable is used by SlackBuild scripts only
# and can be used to change the output location of compiled packages.
#export OUTPUT=${OUTPUT:-/tmp}

　通常のユーザーであれば、デフォルト値のままでも問題ないだろう。ただし私の場合はコメントアウトされていた最終行を有効化し、出力先のディレクトリを/tmpからパッケージビルド専用に使っているフォルダに変更しておいた。

　必要な設定変更後の同ファイルについては/etc/sbopkg/sbopkg.confとして保存しておけばいい。そしてroot権限下にてsbopkgを起動させるとメインメニューが表示されるので、そこにあるRsyncという1番目のメニュー項目を選択すると、SlackBuilds.orgリポジトリのローカルコピー版がダウンロードされるはずだ。同リポジトリの格納には11MBのディスクスペースを消費するが、1,000以上のパッケージがビルド可能になることを考えると、この程度は妥当な負担と言えるだろう。いずれにせよこの1つのステップを実行するだけで、SlackBuildスクリプト群およびすべての関連ファイルが一括で取得できてしまうのだ（ただしソースファイルは除く）。

sbopkg1_thumb.jpg
sbopkg

　sbopkgではメニュー形式のインタフェースを介して、Webサイト形態のリポジトリにおける検索とブラウジングに相当する操作を行えるようになっている。ここでパッケージをビルドするには、まず最初に当該パッケージのメニューに移動しなくてはならない。このメニューには、readmeや.infoやslack-desc（パッケージの簡単な説明）などのファイルおよびSlackBuildスクリプトの閲覧用オプションの他、SlackBuildスクリプトの編集、編集版スクリプトの削除、パッケージのビルド用オプションが用意されている。このうちパッケージのビルド用オプションを選択すると、ソースファイルのダウンロード、SlackBuildスクリプトの実行（独自編集版がある場合はそれを使用）、完成したパッケージのインストールという、通常は手作業にて行う3つのステップがsbopkgにより自動実行されるのである。

　こうしたパッケージのビルド以外にもメインメニューからは、下記のようなSlackBuilds.orgパッケージ管理用の各種オプションにアクセスすることができる。

  • インストール済みSBoパッケージの一覧
  • インストール済みSBoパッケージに対するアップデート候補の一覧
  • キャッシュディレクトリ（ソースファイルの格納先）のコンテンツ表示。閲覧後は2番目のメニューにてソースファイルの削除オプションがユーザーに提示される
  • 永続的なビルドログの閲覧（ログの削除オプションも提示される）

　このうち特に役立つのが、インストールしたサードパーティ系Slackwareパッケージの追跡および、アップデート候補を提示するという機能だ。なおsbopkgでは、Slackwareの方針（SlackBuilds.orgでも同様）に準拠する関係上、依存関係の自動チェック機能は排されているが、依存性に関する情報は各パッケージのreadmeファイルに記載されており、必要なライブラリ群も同リポジトリにて取得できるようになっている。

　sbopkgにはコマンドラインインタフェースも用意されており、そこで使用するオプション群は「sbopkg -h」と入力することで確認できる。コマンドラインによる操作性は、メニュー形式のインタフェースに比して大幅に劣るという訳ではない。例えば「sbopkg -s moria」と入力すると“moria”という文字列を対象としたリポジトリ検索が行われ、検索にヒットしたパッケージについては、readmeファイル、.infoファイル、slack-descファイルおよびSlackBuildスクリプトなどの情報が表示されるのだ。こうして見つかったパッケージについては「sbopkg -b moria」と入力すればビルドが実行され、またそのインストールを実施してよいかの確認メッセージも提示されるようになっている。

　私がsbopkgを試用した限りにおいて、ほとんど問題は発生しなかった。ビルドに失敗したのはOpenOffice.orgだけであり、その原因もOpenOffice.org本体のダウンロードが不完全だったからである。ただし不完全ないし破損していたソースファイルのパッケージビルドに失敗するのは致し方ないとしても、sbopkgの場合はソースファイルを削除した上で再試行するという処理にバグがあるようで、そうしたバグの存在をsbopkgのメーリングリストに報告したところ、作成者のChess Griffin氏は直ちにその対処に取りかかってくれた。

　その他に私が遭遇した不備は、SlackBuildスクリプトの編集時に感じた不満ぐらいのものだ。ここではviがデフォルトエディタとされており、もちろんvi自体には何の罪もないのだが、Emacsに慣れきっている私としては短時間ながらも不自由をかこつことになったのである。もっともsbopkgのmanページにある下記のような旨の記載を見ると、こうした不満を感じるユーザーの存在はあらかじめ予想されていたことのようだ。

sbopkgの一部機能は、コマンドライン操作時におけるテキストファイル閲覧用のpagerおよびSlackBuild編集に用いるエディタなどの外部バイナリに依存しており……、ダイアログ形式のインタフェース下でsbopkgを使用する際にSlackBuildの編集機能は$EDITORを参照しますが、$EDITORが未設定の場合はデフォルトで‘vi’が使用されます。sbopkgにて用いるエディタをnanoなどに変更したい場合は、エディタ指定をエクスポートできる~/.bashrcといった設定ファイルにて必要な情報を記述してください。

　実際、rootユーザー用の.bashrcファイルにexport EDITOR='emacs -nw'という指定を追加することでsbopkgの挙動は変更できたが、私の好みとしてはシステム全域に影響するような設定変更は避けて、/etc/sbopkg/sbopkg.confの$editor変数として指定する方がよいのではないかと感じている。

　このようにsbopkgの機能はSlackBuilds.orgリポジトリをオペレーティングシステムに統合するというものであり、その活用はサードパーティ系Slackwareパッケージのビルドとインストールを大幅に簡単化してくれるはずだ。現行のsbopkgは鋭意開発中という段階ではあるものの、そこに装備された有用かつ強力な機能は、既に安定して利用可能なレベルの完成度にあると評していいだろう。

Drew Amesは、ペンシルバニア州ハリスバーグにてトランスポーテーションプランナとして活動している。

Linux.com 原文（2008年10月1日）