ハンドブック:PPC/Portage/高度
Portage の高度な機能への導入
多くの読者にとって、これまでに受け取った情報は Linux のすべての操作をするのに十分です。しかし、Portage にはより多くのことができます; その機能の多くは高度なカスタマイズのためのものであるか、またはあまり一般的でない特定のケースにのみ適用できるものです。
もちろん、高い柔軟性により、膨大な数の潜在的な状況がありえます。それらすべてをここに文書化することは不可能でしょう。代わりに、特定のニッチに合わせて補足できるよう、いくつかの一般的な問題に焦点を当てることをゴールとします。こうした微調整や豆知識は Gentoo wiki のあちこちで他にも見つけることができます。
これらの追加的機能の全てではないとしても大部分は、Portage とともに提供されるマニュアルページを探ることで簡単に見つけることができます。
user $man portage
user $man make.conf
最後に、これらは高度な機能であり、正しく設定されていないとデバッグやトラブルシューティングがずっと難しくなるかもしれない、ということを知っておいてください。バグ報告を作成する際には、これらのカスタマイズについて明示的に言及することを忘れないようにしてください。
パッケージごとの環境変数
/etc/portage/env を使用する
デフォルトでは、パッケージのビルドでは CFLAGS、MAKEOPTS その他の /etc/portage/make.conf で定義されている環境変数を使用します。場合によっては特定のパッケージに対して異なる変数を提供することが有益です。そうするために、Portage は /etc/portage/env ディレクトリと /etc/portage/package.env ファイルの使用をサポートしています。
/etc/portage/package.env ファイルは、環境変数の変更が必要なパッケージと、どの識別子ファイルを適用するか Portage に示すための特定の識別子のリストを含んでいます。識別子の名前は自由書式です。Portage は大文字小文字を区別して識別子とまったく同じ名前のファイルを探します。さらなる詳細については次の例を参照してください。
例: 特定のパッケージでデバッグを使用する
例として、media-video/mplayer パッケージでデバッグを有効化します。
/etc/portage/env/debug-cflags というファイルでデバッグ用の変数をセットします。ファイル名は任意に選択できますが、もちろん、後でそのファイルが存在する理由を確認するときに明確にわかるように、ファイルの目的を反映させましょう。/etc/portage/env ディレクトリがまだ存在しない場合はそれを作成する必要があるでしょう:
root #mkdir /etc/portage/env/etc/portage/env/debug-cflagsデバッグのために特定の変数を設定する# デバッグのために CFLAGS に -ggdb を追加する
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"
次に、package.env ファイル内の新しいデバッグ識別子を使用するように、media-video/mplayer パッケージにタグ付けします:
/etc/portage/package.envmplayer パッケージで debug-cflags 識別子を使用するmedia-video/mplayer debug-cflags
emerge のプロセスにフックする
/etc/portage/bashrc と関連ファイルを使用する
Portage が ebuild を扱う場合には、bash 環境を使用してその内部でさまざまなビルド関数 (src_prepare、src_configure、pkg_postinst など) を呼びます。Portage ではシステム管理者が特定の bash 環境を設定することができます。
特定の bash 環境を使用する利点は、emerge で行われる各段階において emerge のプロセスにフックできることです。これはすべての emergeに対して(/etc/portage/bashrc を通して)、またはパッケージごとの環境を使用して(前に説明したように /etc/portage/env を通して)行うことができます。
Portage は、いわゆるフェーズフック関数 (phase hook functions) が /etc/portage/bashrc で定義されていれば、それらを呼び出します。これらの関数は pre_フェーズ名 および post_フェーズ名の命名規則に従っています。例えば、Portage は pkg_postinst フェーズ関数を呼び出した直後に、post_pkg_postinst フックを呼び出すでしょう。
プロセスにフックするために、bash 環境では ebuild 開発の際に常に利用可能な変数 (CATEGORY、P、PF、等) を確認することができます。これらの変数の値をもとに、追加の段階や関数を実行できます。
例: ファイルデータベースを更新する
この例では、/etc/portage/bashrc ファイルを使用していくつかのファイルデータベースアプリケーションを実行し、データベースがそのシステムで最新の状態になるようにします。この例で使用されているアプリケーションは aide (an intrusion detection tool) と(mlocate と共に使用される) updatedb ですが、これらは例として意図されています。これをAIDEのためのガイドとは考えないでください。
この場合に /etc/portage/bashrc を使用するには、postinst (ファイルのインストール後) と postrm (ファイルの削除後) のフェーズに「フック」する必要があります。なぜなら、これらがファイルシステム上のファイルが変更された時点だからです。
/etc/portage/bashrcpostinst および postrm フェーズにフックするmy_database_update() {
echo ":: Calling aide --update to update its database"
aide --update
echo ":: Calling updatedb to update its database"
updatedb
}
post_pkg_postinst() { my_database_update; }
post_pkg_postrm() { my_database_update; }
ebuild リポジトリ同期の後にタスクを実行する
ロケーション /etc/portage/postsync.d を使用する
ebuild の各フェーズへのフックに加えて、Portage はフック機能のためのもう一つの選択肢を提供します: postsync.d です。これらの種類のフックは Gentoo ebuild リポジトリの更新 (同期ともいいます) の後に実行されます。Gentoo リポジトリの更新後にタスクを実行するには、スクリプトを /etc/portage/postsync.d ディレクトリの中に置いてください。ディレクトリ内のすべてのファイルが実行可能としてマークされていることを確認してください、そうでないと実行されません。
例: eix-update を実行する
eix-sync をリポジトリの同期に使用していない場合でも、eix-update という名前の /usr/bin/eix へのシンボリックリンクを /etc/portage/postsync.d に置くことで、eix データベースを emerge --sync (または emerge-webrsync)の後に更新することができます。
root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update異なる名前を選択した場合は代わりに /usr/bin/eix-update を実行するスクリプトにしなければなりません。eix バイナリは、どの関数を実行するか判断するために自身がどのように呼び出されたのかを検査します。eix を指すにもかかわらず eix-update という名前でないシンボリックリンクが作成された場合、正しく動作しないでしょう。
profile の設定を上書きする
/etc/portage/profile を使用する
デフォルトでは、Gentoo は /etc/portage/make.profile (ターゲットプロファイルのディレクトリへのシンボリックリンク) ターゲットプロファイルのディレクトリへのシンボリックリンクが指すプロファイルに含まれている設定を使用します。これらのプロファイルは、(parent ファイルを通して) 他のプロファイルから継承した設定と独自の設定両方を定義しています。
/etc/portage/profile を使用することで、システム管理者はパッケージ (どのパッケージが system セットの一部として扱われるか)、強制される USE フラグなどのプロファイル設定を上書きすることができます。
例: nfs-utils を system セットに追加する
NFS ベースのファイルシステムを重要なファイルシステムに使用する場合、net-fs/nfs-utils をシステムパッケージとしてマークし、管理者がこれを unmerge しようと試みた際には Portage が厳重に警告を出すようにする必要があるでしょう。
これを実現するには、パッケージの先頭に * (アスタリスク記号) を付けて /etc/portage/profile/packages ファイルに追加する必要があります:
/etc/portage/profile/packagesnet-fs/nfs-utils をシステムパッケージとしてマークする*net-fs/nfs-utils
非標準のパッチを適用する
/etc/portage/patches/ 内のユーザパッチを使用してソースコードにパッチを適用する
ユーザパッチは、インストールの前にソースが展開される時点で、パッケージのソースコードにパッチを適用する方法を提供します。これは未解決のバグに対する上流のパッチを適用したり、あるいは単にローカルでのカスタマイズのために、有用なことがあります。
パッチは /etc/portage/patches/ に置く必要があります。これらはパッケージのインストール中に自動的に適用されるでしょう。
パッチは以下のディレクトリのうちいずれかに置くことができます:
- /etc/portage/patches/${CATEGORY}/${P}/ 例: /etc/portage/patches/dev-lang/python-3.3.5-r1/
- /etc/portage/patches/${CATEGORY}/${PN}/ 例: /etc/portage/patches/dev-lang/python-3.4.2/
- /etc/portage/patches/${CATEGORY}/${P}-${PR}/ 例: /etc/portage/patches/dev-lang/python-3.3.5-r0/
例: Firefox にパッチを適用する
www-client/firefox パッケージは既に ebuild 内で eapply_user を呼んでいる (暗黙的にかもしれません) 多くのパッケージの一つなので、特に何かを上書きする必要はありません。
何らかの理由 (たとえば、開発者がパッチを提供し、報告されたバグがこれによって解決されるか確認するよう頼まれた場合) で Firefox をパッチしたい場合、必要なのはパッチを /etc/portage/patches/www-client/firefox/ (パッチが後のバージョンに干渉しないように、フルネームとバージョンを使用した方がよいかもしれません) に置き、Firefox を再度ビルドすることだけです。