ハンドブック:PPC64/Portage/高度

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Handbook:PPC64/Portage/Advanced and the translation is 100% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎polski • ‎русский • ‎українська • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어
PPC64 ハンドブック
インストール
インストールについて
メディアの選択
ネットワーク設定
ディスクの準備
stage3のインストール
Gentooベースシステムのインストール
カーネルの設定
システムの設定
ツールのインストール
ブートローダの設定
締めくくり
Gentooの操作
Portageについて
USEフラグ
Portageの機能
Initスクリプトシステム
環境変数
Portageの操作
ファイルとディレクトリ
変数
ソフトウェアブランチの併用
追加ツール
カスタムPortageツリー
高度な機能
ネットワーク設定
はじめに
高度な設定
モジュール式ネットワーク
無線
機能の追加
動的な管理


はじめに

多くのユーザーにとって、これまでに受け取った情報は Linux のすべての操作をするのに十分です。しかし、Portage にはより多くのことができます; その機能の多くは上級ユーザー向けであるか、またはあまり一般的でない特定のケースにのみ適用できるものです。それでも、このことはこれらの機能を文書化しない理由にはなりません。

もちろん、高い柔軟性により、膨大な数の潜在的な状況がありえます。それらすべてをここに文書化することは不可能でしょう。代わりに、個人的なニーズに合わせて変えられるよう、いくつかの一般的な問題に焦点を当てたいと思います。より多くの微調整や豆知識は Gentoo Wiki のあちこちで見つけることができます。

これらの追加的機能の全てではないとしても大部分は、Portage が提供しているマニュアルページを探ることで簡単に見つけることができます。

user $man portage
user $man make.conf

最後に、これらは高度な機能であり、正しく動かない場合にデバッグやトラブルシューティングがとても難しくなるかもしれない、ということを知っておいてください。バグに遭遇してバグ報告を作成する際には、これらに言及することを忘れないようにしてください。

パッケージごとの環境変数

/etc/portage/env を使用する

デフォルトでは、パッケージのビルドでは CFLAGSMAKEOPTS その他の /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 というファイルでデバッグ用の変数をセットします。名前は任意に選択できますが、もちろん、後でなぜ変更が加えられているのか明確にするために変更の理由を反映させましょう。

FILE /etc/portage/env/debug-cflagsデバッグのための特定の変数
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

次に、media-video/mplayer パッケージをこの内容を使用するようにタグ付けします:

FILE /etc/portage/package.envmplayer パッケージで debug-cflags を使用する
media-video/mplayer debug-cflags

emerge のプロセスにフックする

/etc/portage/bashrc と関連ファイルを使用する

Portage が ebuild を扱う場合には、bash 環境を使用してその内部でさまざまなビルド関数(src_preparesrc_configurepkg_postinst など)を呼びます。しかし、Portage ではユーザーが特定の bash 環境を設定することもできます。

特定の bash 環境を使用する利点は、emerge で行われる各段階においてユーザーが emerge のプロセスにフックできることです。これはすべての emergeに対して(/etc/portage/bashrc を通して)、またはパッケージごとの環境を使用して(前に説明したように /etc/portage/env を通して)行うことができます。

プロセスにフックするために、bash 環境では ebuild 開発の際に常に利用可能な(PPF などのような)変数と同様に、EBUILD_PHASECATEGORY 変数も取り上げることができます。これらの変数の値をもとに、追加の段階/関数を実行できます。

例: ファイルデータベースを更新する

この例では、/etc/portage/bashrc を使用していくつかのファイルデータベースアプリケーションを実行し、データベースがそのシステムで最新の状態になるようにします。この例で使用されているアプリケーションは aide (an intrusion detection tool) と(mlocate と共に使用される) updatedb ですが、これらは例として意図されています。これをAIDEのためのガイドとは考えないでください ;-)

この場合に /etc/portage/bashrc を使用するには、postrm (ファイルの削除後)と postinst (ファイルのインストール後)をフックする必要があります。なぜなら、これらがファイルシステム上のファイルが変更された時点だからです。

FILE /etc/portage/bashrcpostinst および 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
Note
異なる名前を選択した場合は代わりに /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 に追加します:

FILE /etc/portage/profile/packagesnfs-utils をシステムパッケージとしてマークする
*net-fs/nfs-utils

非標準のパッチを適用する

epatch_user を使用する

Note
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 を再度ビルドすることだけです。