Ubuntu Weekly Recipe

第311回 autopkgtestでパッケージのテストを自動化する

この記事を読むのに必要な時間:およそ 5 分

年末年始ムードも落ち着き,今年も年頃の男女が共にそわそわする一大イベントのシーズンがやってきました。その結果に一喜一憂し,人によっては人生を左右することもあるイベント……そうテスト(入試や学年末試験など)ですね。そんなわけで今回はパッケージのテストについてお話しします。

Debian形式のパッケージとそのテストツール

UbuntuはDebianをベースにしたディストリビューションであり,パッケージ管理システムもパッケージ形式もDebianと同じものがそのまま使われています。ユーザーがソフトウェアセンターやapt-getコマンドからダウンロードするものの実態は,このDebian形式の「バイナリパッケージ」と呼ばれるものなのです。

あるソフトウェアのバイナリパッケージはおもに次のようなルートで生成されます。

  1. ソフトウェアの開発元(アップストリーム)からソースコードのアーカイブを取得する
  2. ソースコードをDebianのルールに従ってビルド,インストールするためのスクリプト群(debian/ディレクトリ)を追加する
  3. アーカイブとdebian/ディレクトリを元に「ソースパッケージ」を作成する
  4. ソースパッケージをビルドし,バイナリパッケージを作成する

ほとんどの工程は半自動化されており,パッケージング用のいくつかのスクリプトを駆使することで実現します。そのためDebianやUbuntuの開発者が最も時間と頭を使うのは,ユーザーからの不具合報告を元にユーザーと一緒に原因を追求したうえで2.のdebian/ディレクトリの中を調整したり,その結果を必要に応じてアップストリームに報告したりする部分になります。

アップストリームの新規リリースに追随したり,何らかの不具合を修正すれば新しいパッケージがリリースされます。これが「ちゃんとビルドできるのか」⁠ちゃんとインストールやアップグレードできるのか」⁠ちゃんと動くのか」をテストするのも開発者の作業の1つです。

ビルドテスト

パッケージを修正したらまず行うことはビルドできるかどうかの確認です。しかもただローカル環境でビルドするのではなく,パッケージのビルドに必要なものだけが揃ったよりクリーンな環境でのビルドを確認することが重要です。そんなクリーンな環境を準備し,自動的にビルドに必要なパッケージを揃えて,ビルドを行ってくれるツールとして,pbuilderやcowbuilderなどが使われます。

ある時点でパッケージをビルドできたとしても,ツールチェインの更新や依存ライブラリのバージョンアップ,パッケージ名の変遷などが原因で,ビルドできなくなること,⁠FTBFS(Fails To Build From Source)⁠と呼ばれる問題がしばしば発生しているのです。Ubuntuでも定期的にリポジトリ全体をリビルドすることでFTBFSの早期発見を心がけています注1)⁠

注1)
たとえばUbuntu Weekly Topicsの2014年2月7日号「その他のニュース」にも,14.04でのリビルド結果の報告が掲載されています。

パッケージのポリシー

Debianのパッケージはただソフトウェアをインストールするだけでなく,より「お行儀良く」インストールできることが求められます。そうしないとDebianの膨大なパッケージ資産がお互いに干渉することなく1つのシステムで共存したり,ソフトウェアごとのアップグレードに追随することが難しくなるからです。そこでDebianではたとえばDebianポリシーマニュアルを策定しており,DebianをベースにしたUbuntuでもこのポリシーに従うことが求められています。

と言ってもこの膨大なポリシーすべてに従っているかどうかを手作業で確認するのは至難の業です。機械でできることは機械に任せる,ということでDebianには「lintian」と呼ばれるパッケージの静的解析ツールが存在します。lintianコマンドにソースパッケージやバイナリパッケージを渡すことで,インストールされるファイルがFilesystem Hierarchy Standardに従っているか,アーキテクチャごとに適切なバイナリが生成されているか,依存関係に明らかな間違いは存在しないかといった基本的なことから,実行ファイルごとにマニュアルは揃っているか,ドキュメントのスペルに間違いはないかといったパッケージの品質に関わる部分まで,いろいろなことを確認してくれるのです。

Debianの場合,各パッケージについてlintianを実行した結果は,Lintian Reportsにまとまっています。

インストールやアップグレードのテスト

ビルドも問題なく,とくにポリシーにも違反していないとなれば次に確認するのは,そのバイナリパッケージが正しくインストールされるかどうか,です。さらにはリポジトリにある既存のバージョンをインストールした状態からアップグレードできるかどうか,アンインストールできるかどうか,その際に余計なデータを残していないかどうか,なども確認したほうが良いでしょう。

これを自動的に行ってくれるのがpiupartsと言うコマンドです。piupartsを使えば,pbuilderのときと同様にクリーンな環境を用意したうえで,インストール,アップグレード,アンインストールのいくつかの組み合わせや,それぞれの作業前後のディレクトリツリーの状態のチェックを行ってくれます。

Debianでは,各リリースごとやリリース間ごとの各パッケージのpiupartsの結果が公開されています。ちなみに残念ながらUbuntuは1年ぐらい前までそもそもベースシステムすらpiupartsがパスしない状態になっているなど,まだpiupartsが使える状況にはありませんでした。最近はだいぶ改善してきたので,今後は各パッケージでもpiupartsを積極的に使っていくことになると思います。

動作確認

もちろんインストールするだけでなく,インストールした後にソフトウェアの動作確認も行います。最低でも,不具合が修正されたかどうかの確認は行うことになるでしょう。パッケージによってはリグレッションが発生していないかの確認や何らかのテストツールを使うことになるかもしれません。

そんな様々なテストを行うことで,より品質の高いパッケージがアーカイブで公開されることになるのです。

著者プロフィール

柴田充也(しばたみつや)

Ubuntu Japanese Team Member。数年前にLaunchpad上でStellariumの翻訳をしたことがきっかけで,Ubuntuの翻訳にも関わるようになりました。

コメント

コメントの記入