This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
ハンドブック:IA64/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 は変数を /etc/portage/env/識別子 ファイルから探します。
例: 特定のパッケージでデバッグを使用する
例として、media-video/mplayer パッケージでデバッグを有効化します。
まずはじめに、/etc/portage/env/debug-cflags というファイルでデバッグ用の変数をセットします。名前は任意に選択できますが、もちろん、後でなぜ変更が加えられているのか明確にするために変更の理由を反映させましょう。
/etc/portage/env/debug-cflags
デバッグのための特定の変数CFLAGS="-O2 -ggdb -pipe" FEATURES="${FEATURES} nostrip"
次に、media-video/mplayer パッケージをこの内容を使用するようにタグ付けします:
/etc/portage/package.env
mplayer パッケージで 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 を通して)行うことができます。
プロセスにフックするために、bash 環境では ebuild 開発の際に常に利用可能な(P、PF などのような)変数と同様に、EBUILD_PHASE、CATEGORY 変数も取り上げることができます。これらの変数の値をもとに、追加の段階/関数を実行できます。
例: ファイルデータベースを更新する
この例では、/etc/portage/bashrc を使用していくつかのファイルデータベースアプリケーションを実行し、データベースがそのシステムで最新の状態になるようにします。この例で使用されているアプリケーションは aide (an intrusion detection tool) と(mlocate と共に使用される) updatedb ですが、これらは例として意図されています。これをAIDEのためのガイドとは考えないでください ;-)
この場合に /etc/portage/bashrc を使用するには、postrm
(ファイルの削除後)と postinst
(ファイルのインストール後)をフックする必要があります。なぜなら、これらがファイルシステム上のファイルが変更された時点だからです。
/etc/portage/bashrc
postinst および postrm フェーズにフックするif [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ]; then echo ":: Calling aide --update to update its database" aide --update echo ":: Calling updatedb to update its database" updatedb fi
--sync の後にタスクを実行する
ロケーション /etc/portage/postsync.d を使用する
ここまで ebuild プロセスのフックについて話してきました。しかしながら、Portage はもう一つの重要な機能を備えています: Gentoo リポジトリの更新です。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/packages
nfs-utils をシステムパッケージとしてマークする*net-fs/nfs-utils
非標準のパッチを適用する
epatch_user を使用する
epatch_user
関数は EAPI 5以下に適用できます。EAPI 6以上については eapply_user
を参照してください。いくつかの ebuild を同様に管理するために、ebuild の開発者はよく使われる関数を定義した eclass (これらはシェルライブラリーです)を使用します。これらの eclass の一つが epatch_user
と呼ばれる便利な関数を提供する eutils.eclass です。
epatch_user
関数は、/etc/portage/patches/<category>/<package>[-<version>[-<revision>]] の最初に見つかったディレクトリーにあるソースコードパッチを適用します。残念なことにすべての ebuild が自動的にこの関数を呼ぶわけではないので、パッチをこの場所に置くだけでは動作しない場合があるでしょう。
幸運なことに、ユーザーはこの章で先に提供した情報を使って、例えば prepare フェーズにフックすることでこの関数を呼ぶことができます。この関数は必要な回数だけ呼ぶことができます - 関数はパッチを一回だけ適用します。
例: Firefox にパッチを適用する
www-client/firefox パッケージは既に ebuild 内で epatch_user
を呼んでいる多くのパッケージの一つなので、特に何かを上書きする必要はありません。
何らかの理由(たとえば、開発者がパッチを提供し、報告されたバグがこれによって解決されるか確認するよう頼まれた場合)で Firefox をパッチしたい場合、必要なのはパッチを /etc/portage/patches/www-client/firefox(パッチが後のバージョンに干渉しないように、フルネームとバージョンを使用した方がおそらくよいでしょう) に置き、Firefox を再度ビルドすることだけです。