Handbook:Parts/Working/USE/ja

USE フラグの 背景にある発想
Gentooをインストールするとき(あるいは他のディストリビューションや、この際もっと言えば他のOSでもかまいませんが)、ユーザーは自らが扱う環境に応じて選択を行います. サーバー向けのセットアップは、ワークステーション向けのセットアップとは異なります. ゲーミングワークステーションと、3Dレンダリングワークステーションは違います.

これはどのパッケージを選んでインストールするかということのみならず、あるパッケージがどのような機能をサポートするべきかについても言えることです. もしOpenGLが必要とされていないのなら、なぜわざわざOpenGLをインストールして管理し、ほとんどのパッケージでOpenGLサポートをビルドする必要があるでしょう？　もしKDEを使いたくないなら、KDEなしで完璧に動作するパッケージを、どうしてわざわざKDEサポートつきでコンパイルする必要があるでしょうか？

ユーザーが何をインストール/有効化し、何をしないのか決定するのを助けるため、Gentooはユーザーに、環境を簡単なやり方で指定するよう求めます. これにより、ユーザーは自分が何を本当に欲しているのかを決定できるようになり、Portageが有益な判断をするためのプロセスが簡単になります.

USE フラグの定義
USEフラグを入力しましょう. このフラグは、あるコンセプトに対するサポートと依存の情報を表すキーワードです. あるUSEフラグが定義されると、Portageは選択されたキーワードに関するサポートが必要とされているのを知ることになります. 当然、これによってパッケージへの依存の情報も変更されます.

具体例を見てみましょう:  キーワード. もしこのキーワードが USE 変数に含まれていないならば、オプションでKDEをサポートしているすべてのパッケージは、KDEサポート"なし"でコンパイルされます. オプションでKDEに依存しているすべてのパッケージは、KDEのライブラリを(依存先として)インストール"せず"にインストールされます. もし kde キーワードが定義されているならば、これらのパッケージはKDEサポート"あり"でコンパイルされ、KDEのライブラリも依存先としてインストール"される"ことになります.

的確にキーワードを定義することで、システムはユーザーの具体的な必要に合わせて仕立てられることになります.

どんなUSEフラグが存在するのか
USE フラグには２種類あります. グローバル USE フラグと、ローカル USE フラグです.


 * "グローバル" USEフラグは、いくつかのパッケージに、システムワイドに使われるものです. ほとんどの人にとって、USEフラグといえばこれを指します. 利用できるグローバルUSEフラグの一覧は、メインサイト あるいはローカルの ファイルにあります.
 * "ローカル" USEフラグは、単一のパッケージに、パッケージ固有の選択のために使われるものです. 利用できるローカルUSEフラグの一覧は、メインサイト あるいはローカルの ファイルにあります.

永続的なUSEフラグの宣言
前述の通り、すべてのUSEフラグは USE 変数の中で宣言されます. ユーザーがUSEフラグを探しやすく、また選びやすくするために、デフォルトのUSE設定が既に提供されています. この設定は、Gentooユーザーに一般的に用いられるだろうと考えられるUSEフラグを集めたものです. このデフォルト設定は、選択されたプロファイルの一部である ファイルで宣言されています.

システムが従うプロファイルは、 symlinkが指し示す先にあります. それぞれのプロファイルは他のプロファイルの上で働くため、結果は全てのプロファイルの合計ということになります. トップのプロファイルはbaseプロファイルです.

現在アクティブなUSEフラグを全て見るのには、を使います:

見ての通り、この変数には既にかなり多くのキーワードが含まれています. しかし、のいかなるファイルも、個人的な必要に合わせて USE 変数を仕立てるために変更してはいけません. これらのファイルへの変更は、Gentooリポジトリを更新すると元通りになってしまいます！

このデフォルト設定を変更するには、 USE 変数のキーワードを追加または削除してください. の中の USE 変数定義によって、この変更をグローバルに行うことができます. この変数には必要になった追加のUSEフラグを増やすことも、もはや不要になったUSEフラグを取り去ることもできます. 後者は、キーワードの先頭にマイナス記号をつけることで行います.

例えば、KDEとQTのサポートを削除し、ldapのサポートを追加したいのなら、次のUSEを で定義できます:

個別のパッケージに対して USE フラグを指定する
時に、あるUSEフラグを1つの(もしくは2つの)アプリケーションで有効にしたいが、システムワイドにはしたくないということがあるでしょう. これを行うためには、を編集してください. これは多くの場合に単一のファイルですが、ディレクトリであることもできます. 詳しくは を見てください. 次の例では、が単一のファイルだと仮定しています.

たとえば、mysqlでのみberkdbをサポートするには:

同様に、あるアプリケーションでのみ明示的にUSEフラグを無効にすることもできます. たとえば、PHPでjavaサポートを無効にする(が、他の全てのパッケージでは のUSEフラグ設定を通じて有効にする)には:

USEフラグの一時的な宣言
時に、短い一時の間だけUSEフラグをセットすることが必要になるでしょう. を二度(USEの変更を行い、また無かったことにするために)編集するかわりに、単に USE 変数を環境変数として宣言しましょう. この設定はこの際入力したコマンドに対してのみ適用されるということは、ゆめゆめ忘れないでください. このアプリケーションを次にemergeすると(これは明示的にそうすることもあれば、システムアップデートの一部として行われることもあるでしょう)、この(一時的な)USEフラグの定義を通じて引き起こされた変更は失われることになります.

次の例では、seamonkeyのインストールの間、USE設定から一時的にjavaを取り除きます:

優先順位
当然、どの設定がUSE設定に関して優先されるかには、れっきとした優先順位があります. USE設定の優先順位は、優先度順に(優先度が低いものから)並べると、次のようになっています:
 * 1) あなたのプロファイルの一部の  ファイルで宣言されたデフォルトのUSE設定
 * 2)  でのユーザー定義のUSE設定
 * 3)  でのユーザー定義のUSE設定
 * 4) 環境変数としてのユーザー定義のUSE設定

Portageから見た最終的なUSE設定を見るには、 を実行してください. これによって、関係のある全ての変数( USE 変数を含む)が、Portageが知っている現在の定義とともにリストされます.

システム全体を新たなUSEフラグに適合させる
USEフラグに変更を加えたあと、必要な変更を反映させるために、システムをアップデートする必要があります. そのためには、 に  オプションを与えてください:

次に、Portageのdepcleanを実行し、"古い"システムでemergeされていたけれども、新しいUSEフラグでは不要になった条件付きの依存パッケージを削除しましょう.

depcleanが完了したら、 を実行し、削除されたかもしれないパッケージが提供していた共有オブジェクトに対して動的リンクされていたアプリケーションをリビルドしましょう. は パッケージの一部です. これを最初にemergeしておくのを忘れないようにしてください.

これらの全てを完遂したとき、システムは新たなUSEフラグ設定を用いることになります.

利用可能な USE フラグを表示する
それでは、seamonkeyの例を見てみましょう: これはどんなUSEフラグに影響されるのでしょう？　確かめるために、を  と   オプションつきで使います:

これができるツールは だけではありません. 実際、パッケージの情報に特化した というツールが、 パッケージに含まれています.

では、 を"uses"引数つきで実行し、あるパッケージのUSEフラグを見てみましょう. 例えば、gnumeric パッケージの場合:

REQUIRED_USE 条件を満足させる
いくつかのebuildは、正常に動作するために、特定のUSEフラグの組み合わせを要求あるいは禁止します. これは、 REQUIRED_USE 式に書かれた条件の組み合わせによって表現されます. この条件によって、全ての機能と依存関係が充足していることと、ビルドが成功し、期待通りに動作することが保証されます. これらの一つでも満たしていない場合には、emergeはあなたに警告を出し、問題の解決を求めます.

この REQUIRED_USE 式の例を、いくつか下に示します: