Gentoo Linux amd64 ハンドブック:Gentoo での作業

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

Contents

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


Portage へようこそ

portageはソフトウェア管理における、Gentooの最も特筆すべき技術革新のひとつです。その高い柔軟性と膨大な量の機能により、Linuxで利用可能な最高のソフトウェア管理ツールであると見なされることもしばしばです。

portageはすべてPythonBashで書かれています。どちらもスクリプト言語なので、ユーザはそのすべてを見ることができます。

ほとんどのユーザはemergeというツールを挟んでPortageを利用することになるでしょう。この章はemergeのmanページにある情報をすべて記述することを目的とはしていません。emergeのオプションの完全な概要については、manページを参照してください:

user $man emerge

Gentoo リポジトリ

Ebuild

Gentooのドキュメントがパッケージという言葉を使うとき、それはGentooリポジトリ上でGentooユーザが利用可能なソフトウェア名のことを指します。Gentooリポジトリとは、Portageがソフトウェアを整備(インストール、検索、クエリ、など)するために必要なすべての情報を含む、ebuildというファイルの集合体です。これらのebuildはデフォルトでは/usr/portageにあります。

ユーザがPortageを使ってソフトウェア名に関してなんらかの操作を行うとき、Portageはシステム上のebuildをベースとして使います。なので、Portageが新しいソフトウェアやセキュリティアップデートを知るために、定期的にシステム上のebuildを更新することが大切です。

Gentooリポジトリの更新

Gentooリポジトリは通常、高速な増分ファイル転送ユーティリティであるrsyncを使って更新されます。emergeコマンドはrsyncのフロントエンドを提供しているので、更新はとても簡単です:

root #emerge --sync

一部のファイアウォールは rsync がミラーに接続するのを制限してしまいます。この場合は毎日生成されるスナップショットを使ってGentooリポジトリを更新しましょう。emerge-webrsync ツールは最新のスナップショットを自動的に取得し、システムにインストールします。

root #emerge-webrsync

システム管理者にとっては、GentooリリースエンジニアリングGPG鍵によって署名されたスナップショットだけを取得したい時にも emerge-webrsync が役に立つことでしょう。これに関する詳細は "Portageの機能" 記事の検証済みのGentooリポジトリスナップショットで読むことができます。

ソフトウェアを保守する

ソフトウェアの検索

Gentooリポジトリでソフトウェアを探す方法は色々あります。そのひとつは emerge 自身を使う方法です。デフォルトでは emerge --search は与えた検索キーワードをタイトル (の一部または全体) に含むパッケージの名前を出力します。

例えば、名前に "pdf" を含むパッケージを探してみましょう:

user $emerge --search pdf

パッケージの説明文も検索対象にするには、--searchdest (か -S) オプションを使います:

user $emerge --searchdesc pdf

この出力には様々な情報が含まれています。各項目にはわかりやすいラベルがついているので、ここでその意味を説明する必要はないですね:

CODE 検索コマンドの出力例
*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

ソフトウェアのインストール

ソフトウェアの名前がわかったら、インストールは emerge コマンドを実行するだけです。例えば gnumeric をインストールするにはこうします:

root #emerge --ask app-office/gnumeric

多くのアプリケーションは互いに依存しあっているので、あるソフトウェアパッケージのインストールにはいくつかの依存パッケージのインストールを伴う場合があります。でも大丈夫、Portageがちゃんと依存関係を見ています。Portageがインストールしようとしているものを確認するには、--pretendオプションを付けます。例えば:

root #emerge --pretend gnumeric

パッケージのインストールの過程で、Portageは(必要なら)ソースコードをインターネット上からダウンロードし、デフォルトでは /usr/portage/distfiles/ に保存します。インストールせずにダウンロードだけさせたい時は、--fetchonly オプションを emerge コマンドにつけます。

root #emerge --fetchonly gnumeric

インストールしたパッケージのドキュメントを探す

多くのパッケージにはドキュメントが付属しています。そしてドキュメントをインストールするかどうかを選択する doc USEフラグが用意されていることがあります。パッケージで doc USEフラグが使われるかどうかは、emerge -vp category/package で調べることができます:

root #emerge -vp media-libs/alsa-lib
These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild   R    ] media-libs/alsa-lib-1.1.3::gentoo  USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB

ドキュメントはそれをインストールしたいパッケージにのみインストールしたいでしょうから、doc USEフラグは /etc/portage/package.use でパッケージごとに指定することをお勧めします。詳しくは USE フラグの節 をご覧ください。

パッケージをインストールすると、ドキュメントはたいてい /usr/share/doc/ 内のパッケージ名のディレクトリで見つけることができます:

user $ls -l /usr/share/doc/alsa-lib-1.1.3
total 16
-rw-r--r-- 1 root root 3098 Mar  9 15:36 asoundrc.txt.bz2
-rw-r--r-- 1 root root  672 Mar  9 15:36 ChangeLog.bz2
-rw-r--r-- 1 root root 1083 Mar  9 15:36 NOTES.bz2
-rw-r--r-- 1 root root  220 Mar  9 15:36 TODO.bz2

ドキュメントファイルを一覧表示するもっと確実な方法は、equery--filter オプションを使うことです。equery は Portage のデータベースを検索するために使われるもので、app-portage/gentoolkit パッケージの一部としてインストールされます:

user $equery files --filter=doc alsa-lib
 * Searching for alsa-lib in media-libs ...
 * Contents of media-libs/alsa-lib-1.1.3:
/usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2
/usr/share/doc/alsa-lib-1.1.3/NOTES.bz2
/usr/share/doc/alsa-lib-1.1.3/TODO.bz2
/usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2

--filter オプションを他のルールとともに使えば、他の種類のファイルのインストール場所を見るためにも使えます。他の機能については equery の man ページで確認できます: man 1 equery

ソフトウェアの削除

ソフトウェアをシステムから削除するには、emerge --unmerge を使います。これはそのパッケージによってインストールされたすべてのファイルを削除するようPortageに指示しますが、ひとつ例外があります。アプリケーションの設定ファイルのうち、ユーザーが変更したものは削除されません。これは後で同じパッケージをインストールしなおした時に再設定する手間を省くためです。

警告
Portageは削除するパッケージが他のパッケージに必要とされているかどうかを確認しません。もっとも、そのパッケージの削除によってシステムが壊れる可能性がある場合は、そのことを警告します。
root #emerge --unmerge gnumeric

パッケージがシステムから削除されても、そのパッケージが必要としたために自動的にインストールしたパッケージはまだ残っています。このような削除可能なパッケージを洗い出すには、emergeの --depclean 機能を使いますが、これは後ほど説明します。

システムの更新

システムをきれいに保つため (そしてもちろん最新のセキュリティアップデートを適用するため) には、日常的にシステムを更新する必要があります。PortageはGentooリポジトリに入っているebuildしか確認しませんから、最初にすることはリポジトリの更新です。Gentooリポジトリが更新できたら、emerge --update @world でシステムを更新することができます。次の例では、Portageが更新したいパッケージを表示してユーザーの確認を待つよう、--ask オプションも指定しています。

root #emerge --update --ask @world

Portageはインストール済みのアプリケーションに新しいバージョンがあるかどうかを調べます。しかし、これは明示的にインストールされたアプリケーション (/var/lib/portage/world に記載されているもの) のみが対象であって、それらの依存パッケージはチェックされません。それら依存パッケージも更新するには、--deep オプションを指定します:

root #emerge --update --deep @world

これでも全てのパッケージが対象というわけではありません。中にはパッケージのコンパイルやビルドに必要なだけで、パッケージのインストール後には不要になる依存パッケージがあります。Portageはこれを "ビルド時依存" と呼びます。これも更新に含めるには --with-bdeps=y を付けます:

root #emerge --update --deep --with-bdeps=y @world

セキュリティアップデートは明示的にインストールしていない (他のプログラムが依存している) パッケージにも配信されることがあるので、時々はこのコマンドを実行するとよいでしょう。

システムのUSE設定を変更したときは、--newuse も指定することをお勧めします。こうすると、その変更に新しいパッケージのインストールや既存パッケージの再コンパイルが必要でないかどうか、Portageが調べてくれます。

root #emerge --update --deep --with-bdeps=y --newuse @world

メタパッケージ

Gentooリポジトリの中には、それ自体は中身を持たず、パッケージの集合をインストールするためだけに用意されたパッケージが存在します。例えば kde-plasma/plasma-meta パッケージは、Plasma関連の様々なパッケージを依存に持つことで、KDE Plasmaデスクトップをインストールします。

このようなパッケージをシステムから削除しようと emerge --unmerge を実行しても、その依存パッケージはシステムに残っているため、あまり効果がありません。

Portage has the functionality to remove orphaned dependencies as well, but since the availability of software is dynamically dependent it is important to first update the entire system fully, including the new changes applied when changing USE flags. After this one can run emerge --depclean to remove the orphaned dependencies. When this is done, it might be necessary to rebuild the applications that were dynamically linked to the now-removed software titles but don't require them anymore, although recently support for this has been added to Portage.

以上のことのすべては3コマンドで行われます:

root #emerge --update --deep --newuse @world
root #emerge --depclean
root #revdep-rebuild

revdep-rebuildapp-portage/gentoolkit パッケージによって提供されているので、忘れずに emerge しておいてください:

root #emerge --ask app-portage/gentoolkit

ライセンス

Portage バージョン 2.1.7 以降、ライセンスを基準にソフトウェアのインストールを許可または拒否することができます。ツリー内のすべてのパッケージは LICENSE エントリを含みます。emerge --search package/category を実行するとパッケージのライセンスが表示されます。

Portage はデフォルトでは、読んだ上で契約に同意する必要のあるソフトウェア利用許諾契約 (EULA) を除き、すべてのライセンスを許可します。

許可するライセンスを制限する変数は ACCEPT_LICENSE と呼ばれ、/etc/portage/make.conf ファイル内で設定できます。次の例はデフォルト値を示しています:

FILE /etc/portage/make.confデフォルトのACCEPT_LICENSE設定
ACCEPT_LICENSE="* -@EULA"

この設定の下では、インストール中に EULA に同意するための操作を求めるパッケージをインストールすることはできません。EULA の無いパッケージはインストールすることができます。

ACCEPT_LICENSE/etc/portage/make.conf 内でグローバルに設定することもできますし、/etc/portage/package.license ファイル内でパッケージ毎に定義することもできます。

たとえば、google-chrome ライセンスを www-client/google-chrome パッケージのために許可するには、/etc/portage/package.license に次の内容を追加してください:

FILE /etc/portage/package.licensegoogle-chromeライセンスをgoogle-chromeパッケージのみについて受諾する
www-client/google-chrome google-chrome

これにより www-client/google-chrome パッケージのインストールは許可しますが、同じライセンスを持っていたとしても www-plugins/chrome-binary-plugins パッケージのインストールは禁止されます。

Important
ライセンスは /usr/portage/licenses/ ディレクトリに保管され、ライセンスグループは /usr/portage/profiles/license_groups ファイルに記録されます。各行の大文字で書かれた最初のエントリはライセンスグループの名前で、それに続くすべてのエントリは個々のライセンスです。

ACCEPT_LICENSE 変数内で定義されるライセンスグループは @ 記号で始まります。よく求められる設定は自由なソフトウェアとドキュメントのインストールのみを許可するものです。これを実現するには、次のように、現在許可されているすべてのライセンスを取り除き(-*を使います)、その後 FREE グループ内のライセンスのみを許可してください:

FILE /etc/portage/make.conf自由ソフトウェアと自由ドキュメントのみを受諾する
ACCEPT_LICENSE="-* @FREE"

ここでいう「自由」とは主に FSFOSI によって定義されている意味です。ライセンスがこれらの要求を満たさないすべてのパッケージは、このシステムにインストールできなくなります。

Portageが文句を言ってきたときは

用語について

前述の通り、Portage は非常に強力で、他のソフトウェア管理ツールにはない多くの機能をサポートしています。これを理解するために、Portage のいくつかの観点について、深追いしすぎない程度に説明していきます。

Portage を使うと、ひとつのパッケージの異なる複数のバージョンをシステム上に共存させることができます。他のディストリビューションはパッケージ名をバージョンにちなんで命名する(例えば freetype と freetype2 のように)ことが多いですが、Portage はスロットSLOT)という技術を使用します。各 ebuild はそのバージョンに応じてひとつのスロットを宣言します。異なるスロットを持つ ebuild は同一システム上に共存できます。例えば、freetype パッケージの ebuild には SLOT="1" のものと SLOT="2" のものが存在します。

同じ機能を提供するものの、実装の異なる複数のパッケージというものもあります。例えば、metalogd、sysklogd、syslog-ng はすべてシステムロガーです。"システムロガー"の利用を前提とするアプリケーションは、例えば、metalogd に依存するわけにはいきません。他のシステムロガーも同じくらい良い選択肢でありうるからです。そこで Portage は仮想(virtual)パッケージというものを許容しています。各システムロガーは、virtual カテゴリの logger 仮想パッケージの"排他的な"依存パッケージとしてリストされていて、アプリケーションはvirtual/logger パッケージに依存すればいいようになっています。このパッケージをインストールすると、すでにロギングパッケージがインストールされていない限り(この場合は仮想パッケージの依存が解決していることになります)、言及されている最初のロギングパッケージがインストールされます。

Gentoo リポジトリのソフトウェアは異なるブランチに所属できます。デフォルトでは、システムは Gentoo が安定している(stable)と考えるパッケージだけが許容されます。ほとんどの新しいソフトウェアタイトルは、コミットされた時点ではテスト中(testing)ブランチに追加されます。stable としてマークする前にまだテストが必要だということです。こうしたソフトウェアの ebuild は Gentoo リポジトリ内に存在していますが、stable ブランチに置かれるまで Portage はこれらをアップデートしません。

一部のアーキテクチャでのみ利用可能なソフトウェアもあります。他のアーキテクチャでは動作しない、テストが不十分、そのソフトウェアを Gentoo リポジトリにコミットした開発者が異なるアーキテクチャ上で動作するか確認できない、などの理由がありえます。

Each Gentoo installation also adheres to a certain profile which contains, amongst other information, the list of packages that are required for a system to function normally.

ブロックされたパッケージ

CODE ブロックされたパッケージについての Portage の警告(--pretend あり)
[blocks B     ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
CODE ブロックされたパッケージについての Portage の警告(--pretend なし)
!!! Error: the mail-mta/postfix package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers.

ebuild には、それが依存するパッケージについて Portage に伝えるためのフィールドが含まれています。DEPEND 変数で宣言されるビルド時依存と、RDEPEND 変数で宣言される実行時依存です。これらの依存パッケージのうち一つが明示的にパッケージや virtual を共存できないとマークしているとき、ブロックが発生します。

最近のバージョンの Portage はささいなブロックであればユーザの手助けなしで対処できますが、ブロックを手動で解決することが必要になる場合もあります。

ユーザはブロックを解決するために、そのパッケージをインストールしないか、コンフリクトしているパッケージを先に unmerge するかを選ぶことができます。上の例でいえば、postfix のインストールをやめるか、先に ssmtp を取り除くか選べます。

特定のアトムを対象にしたブロックもあります。例えば <media-video/mplayer-1.0_rc1-r1 のようなものです。この場合は、ブロックしているパッケージをより新しいバージョンにアップデートすることで、ブロックを取り除くことができるかもしれません。

まだインストールされておらず、今からインストールしようとしている 2 つのパッケージがお互いにブロックしあっている、ということもありえます。このレアケースでは、なぜその両方をインストールする必要があるのか調査してください。ほとんどの場合は片方だけで十分です。もしそうでなければ、Gentoo のバグトラッキングシステムにバグを報告してください。

マスクされたパッケージ

CODE マスクされたパッケージについての Portage の警告
!!! all ebuilds that could satisfy "bootsplash" have been masked.
CODE マスクされたパッケージについての Portage の警告 - 理由
!!! possible candidates are:
  
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

現在のシステムで利用可能でないパッケージをインストールしようとしたときに、このマスキングエラーが発生します。ユーザはシステムで利用可能な別のアプリケーションのインストールを試みるか、パッケージが利用可能としてマークされるまで待つべきです。パッケージがマスクされているのには必ず理由が存在します:

マスク理由 説明
~arch keyword アプリケーションは stable ブランチに入れるために十分なテストがなされていません。数日から数週間待ってからもう一度試してください。
-arch keyword or -* keyword アプリケーションはあなたのアーキテクチャ上で動作しません。パッケージは動作すると確信しているなら、私たちの Bugzilla のウェブサイトでバグを提出してください。
missing keyword アプリケーションはまだあなたのアーキテクチャ上でテストされていません。アーキテクチャ移植チームにパッケージのテストを依頼するか、彼らのためにテストして Bugzilla のウェブサイトで知見を報告してください。
package.mask パッケージが破損している、不安定、あるいはもっと悪い状態であると判明したため、意図的に「使用禁止」としてマークされています。
profile パッケージは現在のプロファイルに適していないことが判明しています。アプリケーションをインストールするとシステムが壊れるか、単に現在使用中のプロファイルと互換性がありません。
license パッケージのライセンスが ACCEPT_LICENSE の値に適合していません。/etc/portage/make.conf または /etc/portage/package.license で設定して、ライセンスまたは正しいライセンスグループを許可してください。

USEフラグの変更が必要

CODE USE フラグ変更要求についての Portage の警告
The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

--autounmask がセットされていないと、次のようなエラーメッセージも表示されるかもしれません:

CODE USE フラグ変更要求についての Portage のエラー
emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

このような警告やエラーは、インストールしようとしているパッケージが他のパッケージに単に依存しているだけでなく、そのパッケージが特定の USE フラグ(またはその集合)とともにビルドされていることも要求するときに発生します。上の例では、パッケージ app-text/feelings が USE="test" とともにビルドされていることを要求していますが、この USE フラグがシステム上でセットされていない状態です。

これを解決するには、要求された USE フラグを /etc/portage/make.conf 内でグローバル USE フラグに追加するか、/etc/portage/package.use 内で特定のパッケージに対してセットしてください。

依存パッケージが見つからない

CODE 依存パッケージの不在についての Portage の警告
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
  
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.

インストールしようとしているアプリケーションは、システムで利用可能でない他のパッケージに依存しています。この問題が既知のものかどうか Bugzilla を確認し、もしそうでなければ報告してくれると助かります。システムが複数のブランチを混ぜる設定になっていなければ、この事態は発生すべきではなく、バグです。

あいまいなebuild名

CODE あいまいな ebuild 名についての Portage の警告
[ Results for search key : listen ]
[ Applications found : 2 ]
  
*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD
  
*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2
  
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

インストールすることが選択されたアプリケーションの名前が複数のパッケージに対応しています。これを解決するには、カテゴリ名も付け加えてください。Portage は何から選べばいいか、マッチしたものを教えてくれるでしょう。

循環依存

CODE 循環依存についての Portage の警告
!!! Error: circular dependencies: 
  
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

インストールする 2 個(またはそれ以上)のパッケージがお互いに依存しているため、インストールできません。これはほとんどの場合 Gentoo リポジトリ内のパッケージのどれかにバグがある状態です。時間をおいて再 sync してからもう一度試してください。Bugzilla をチェックしてこの問題が既知のものであるか確認し、そうでなければ報告することも有益でしょう。

フェッチ失敗

CODE フェッチ失敗についての Portage の警告
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

Portage が与えられたアプリケーションのソースをダウンロードできなかったため、他のアプリケーションのインストール(するものがあれば)を続行しようとしています。この失敗は、正しく同期されていないミラーのために、あるいは ebuild が正しくないダウンロード先を指しているために起こることがあります。ソースを置いているサーバが何らかの理由でダウンしていることも考えられます。

1 時間ほど時間をおいて再試行し、問題が継続しているか確認してください。

システムプロファイルによる保護

CODE プロファイルによって保護されているパッケージについての Portage の警告
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

ユーザがシステムのコアパッケージの一部をなすパッケージを削除しようとしました。パッケージはプロファイルによって必須として記載されているため、システムから削除するべきではありません。

ダイジェスト検証失敗

CODE ダイジェスト検証失敗
>>> checking ebuild checksums
!!! Digest verification failed:

これは Gentoo リポジトリに何かおかしなことが起きていることを示しています - 多くの場合は Gentoo ebuild リポジトリに ebuild をコミットするときのミスによるものです。

ダイジェスト検証に失敗しても、自分でパッケージのダイジェストを再計算しようとしないでください。ebuild foo manifest を実行しても問題の解決にはならないどころか、より状況を悪化させるでしょう。

かわりに、リポジトリが大人しくなるまで 1、2 時間ほど待ってください。このエラーはすぐに気づかれるでしょうが、修正が rsync ミラーたちに浸透していくには少々時間がかかることがあります。Bugzilla をチェックしてすでに誰かが問題を報告しているか確認するか、#gentoo (IRC) で聞いてください。まだであれば、遠慮なく壊れた ebuild のためにバグを提出してください。

バグが修正されたら、Gentoo ebuild リポジトリを再同期して修正されたダイジェストを引っ張ってきてください。

Important
Gentoo ebuild リポジトリを一日一回以上同期しないように気をつけてください。公式の Gentoo ネチケットポリシーに書かれている通り(また emerge --sync を実行したときにも表示される通り)、あまりにも頻繁に同期するユーザは当面の間、それ以上の同期を禁止されます。このポリシーにも繰り返し違反する悪用者は完全にアクセスを禁止されることがあります。再同期が Gentoo の rsync ミラーに過剰な負荷を与えないようにするために、どうしても必要な場合を除いて 24 時間周期で同期されるのを待つのが最善です。




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


USE フラグとは何ですか

USE フラグの 背景にある発想

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

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

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

USE フラグの定義

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

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

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

どんなUSEフラグが存在するのか

USE フラグには2種類あります。グローバル USE フラグと、ローカル USE フラグです。

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

USE フラグを使う

永続的なUSEフラグの宣言

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

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

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

root #emerge --info | grep ^USE
USE="a52 aac acpi alsa branding cairo cdr dbus dts ..."

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

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

例えば、KDEとQtのサポートを削除し、LDAPのサポートを追加したいのなら、次のUSEを /etc/portage/make.confで定義できます:

FILE /etc/portage/make.confmake.conf 内の USE フラグを更新する
USE="-kde -qt4 -qt5 ldap"

個別のパッケージに対して USE フラグを指定する

時に、あるUSEフラグを1つの(もしくは2つの)アプリケーションで有効にしたいが、システムワイドにはしたくないということがあるでしょう。これを行うためには、/etc/portage/package.useを編集してください。package.use は一般的に単一のファイルですが、ファイルを含むディレクトリであることもできます。この記法を使う方法についての詳細は下の Tip や man 5 portageを見てください。次の例では、package.useが単一のファイルだと仮定しています。

たとえば、VLC media player パッケージでのみ Blu-ray をサポートするには:

FILE /etc/portage/package.useVLC の Blu-ray サポートを有効にする
media-video/vlc bluray
Tip
package.use が(単一のファイルではなく)ディレクトリとして既に存在している場合、単に package.use/ ディレクトリの下にファイルを作成することでパッケージのローカル USE フラグを変更できます。どのようなファイル命名法でも動作はしますが、一貫した命名スキームを採用するのが賢明でしょう。命名法の一例として、単にパッケージ名をファイル名として使うというものがあります。たとえば、media-video/vlc のみについて bluray USE フラグをセットするには以下のようにできます:

root #echo "media-video/vlc bluray" >> /etc/portage/package.use/vlc

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

FILE /etc/portage/package.usePHP の bzip2 サポートを無効にする
dev-lang/php -bzip2

USEフラグの一時的な宣言

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

次の例では、Seamonkeyのインストールの間、USE変数から一時的に pulseaudio を取り除きます:

root #USE="-pulseaudio" emerge www-client/seamonkey

優先順位

当然、どの設定がUSE設定に関して優先されるかには、れっきとした優先順位があります。USE設定の優先順位は、優先度順に(優先度が低いものから)並べると、次のようになっています:

  1. あなたのプロファイルの一部の make.defaults ファイルで宣言されたデフォルトのUSE設定
  2. /etc/portage/make.conf でのユーザー定義のUSE設定
  3. /etc/portage/package.use でのユーザー定義のUSE設定
  4. 環境変数としてのユーザー定義のUSE設定

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

root #emerge --info

システム全体を新たなUSEフラグに適合させる

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

root #emerge --update --deep --newuse @world

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

警告
emerge --depclean の実行は危険な操作であり、注意して行われるべきです。提供される"不要になった"パッケージの一覧をダブルチェックし、必要なパッケージが削除されないことを確認してください。次の例では、-p スイッチを追加することで、depcleanがパッケージの一覧表示のみを行い、削除を行わないようにしています:
root #emerge -p --depclean

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

root #revdep-rebuild

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

パッケージ固有の USE フラグ

利用可能な USE フラグを表示する

それでは、seamonkeyの例を見てみましょう: これはどんなUSEフラグに影響されるのでしょう? 確かめるために、emerge--pretend--verbose オプションつきで使います:

root #emerge --pretend --verbose www-client/seamonkey
These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild  N     ] www-client/seamonkey-2.48_beta1::gentoo  USE="calendar chatzilla crypt dbus gmp-autoupdate ipc jemalloc pulseaudio roaming skia startup-notification -custom-cflags -custom-optimization -debug -gtk3 -jack -minimal (-neon) (-selinux) (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite {-test} -wifi" L10N="-ca -cs -de -en-GB -es-AR -es-ES -fi -fr -gl -hu -it -ja -lt -nb -nl -pl -pt-PT -ru -sk -sv -tr -uk -zh-CN -zh-TW" 216,860 KiB
 
Total: 1 package (1 new), Size of downloads: 216,860 KiB

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

root #emerge --ask app-portage/gentoolkit

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

user $equery --nocolor uses =gnumeric-1.12.31
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-office/gnumeric-1.12.31:
 U I
 + + introspection            : Add support for GObject based introspection
 - - libgda                   : Enable database support through gnome-extra/libgda.
 - - perl                     : Enable perl plugin loader.
 + + python                   : Enable python plugin loader.
 + + python_targets_python2_7 : Build with Python 2.7

REQUIRED_USE 条件を満足させる

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

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

説明
REQUIRED_USE="foo? ( bar )" もし foo がセットされているなら、 bar もセットされている必要がある
REQUIRED_USE="foo? ( !bar )" もし foo がセットされているなら、 bar がセットされていてはならない
REQUIRED_USE="foo? ( || ( bar baz ) )" もし foo がセットされているなら、 barbaz の少なくともどちらかはセットされている必要がある
REQUIRED_USE="^^ ( foo bar baz )" foobarbaz のうちいずれかただ一つのみがセットされている必要がある
REQUIRED_USE="|| ( foo bar baz )" foobarbaz のうち少なくとも一つがセットされている必要がある
REQUIRED_USE="?? ( foo bar baz )" foobarbaz のうち二つ以上がセットされていてはならない



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


Portage の機能

Portage has several additional features that make the Gentoo experience even better. Many of these features rely on certain software tools that improve performance, reliability, security, ...

To enable or disable certain Portage features, edit /etc/portage/make.conf and update or set the FEATURES variable which contains the various feature keywords, separated by white space. In several cases it will also be necessary to install the additional tool on which the feature relies.

Not all features that Portage supports are listed here. For a full overview, please consult the make.conf man page:

user $man make.conf

To find out what FEATURES are set by default, run emerge --info and search for the FEATURES variable or grep it out:

user $emerge --info | grep ^FEATURES=

分散コンパイル

distcc を使う

distcc is a program to distribute compilations across several, not necessarily identical, machines on a network. The distcc client sends all necessary information to the available distcc servers (running distccd) so they can compile pieces of source code for the client. The net result is a faster compilation time.

More information about distcc (and how to have it work with Gentoo) can be found in the Distcc article.

distcc のインストール

Distcc ships with a graphical monitor to monitor tasks that the computer is sending away for compilation. This tool is automatically installed if USE=gnome or USE=gtk is set.

root #emerge --ask sys-devel/distcc

Portage の distcc サポートを有効にする

Add distcc to the FEATURES variable inside /etc/portage/make.conf. Next, edit the MAKEOPTS variable and increase the number of parallel build jobs that the system allows. A known guideline is to fill in -jN where N is the number of CPUs that run distccd (including the current host) plus one, but that is just a guideline.

Now run distcc-config and enter the list of available distcc servers. For a simple example assume that the available DistCC servers are 192.168.1.102 (the current host), 192.168.1.103 and 192.168.1.104 (two "remote" hosts):

root #distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Don't forget to run the distccd daemon as well:

root #rc-update add distccd default
root #/etc/init.d/distccd start

中間生成物のキャッシュ

ccache とは

ccache is a fast compiler cache. Whenever an application is compiled, it will cache intermediate results so that, whenever the same program is recompiled, the compilation time is greatly reduced. The first time ccache is run, it will be much slower than a normal compilation. Subsequent recompiles however should be faster. ccache is only helpful if the same application will be recompiled many times (or upgrades of the same application are happening frequently); thus it's mostly only useful for software developers.

For more information about ccache, please visit its homepage.

警告
ccacheは様々なコンパイル時の問題を引き起こすことが知られています。ccacheは時々古いコードオブジェクトや壊れたファイルを保持していることがあり、これはパッケージのemerge失敗につながります。もしこれが起きた場合 ("File not recognized: File truncated" などのエラーがビルドログに現れます) は、バグ報告をする前に ccache を無効にして (/etc/portage/make.confFEATURES="-ccache" を書く) 再コンパイルしてみてください。

ccache のインストール

To install ccache run the following command:

root #emerge --ask dev-util/ccache

Portage の ccache サポートを有効にする

Open /etc/portage/make.conf and add ccache to any values defined in the FEATURES variable. If FEATURES does not exist, then create it. Next, add a new variable called CCACHE_SIZE and set it to 2G:

FILE /etc/portage/make.confEnabling Portage ccache support
FEATURES="ccache"
CCACHE_SIZE="2G"

To check if ccache functions, ask ccache to provide its statistics. Because Portage uses a different ccache home directory, it is necessary to temporarily set the CCACHE_DIR variable:

root #CCACHE_DIR="/var/tmp/ccache" ccache -s

The /var/tmp/ccache/ location is Portage' default ccache home directory; it can be changed by setting the CCACHE_DIR variable in /etc/portage/make.conf.

When running ccache standalone, it would use the default location of ${HOME}/.ccache/, which is why the CCACHE_DIR variable needs to be set when asking for the (Portage) ccache statistics.

ccache を Portage の外で使う

To use ccache for non-Portage compilations, add /usr/lib/ccache/bin/ to the beginning of the PATH variable (before /usr/bin). This can be accomplished by editing ~/.bash_profile in the user's home directory. Using ~/.bash_profile is one way to define PATH variables.

FILE ~/.bash_profileSetting the ccache location before any other PATH
PATH="/usr/lib/ccache/bin:${PATH}"

バイナリパッケージ

ビルド済みパッケージを作る

Portage supports the installation of prebuilt packages. Even though Gentoo does not provide prebuilt packages by itself Portage can be made fully aware of prebuilt packages.

To create a prebuilt package use the quickpkg command if the package is already installed on the system, or emerge with the --buildpkg or --buildpkgonly options.

To have Portage create prebuilt packages of every single package that gets installed, add buildpkg to the FEATURES variable.

More extended support for creating prebuilt package sets can be obtained with catalyst. For more information on catalyst please read the Catalyst FAQ.

ビルド済みパッケージのインストール

Although Gentoo doesn't provide one, it is possible to create a central repository where prebuilt packages are stored. In order to use this repository, it is necessary to make Portage aware of it by having the PORTAGE_BINHOST variable point to it. For instance, if the prebuilt packages are on ftp://buildhost/gentoo:

FILE /etc/portage/make.confAdd PORTAGE_BINHOST location
PORTAGE_BINHOST="ftp://buildhost/gentoo"

To install a prebuilt package, add the --getbinpkg option to the emerge command alongside of the --usepkg option. The former tells emerge to download the prebuilt package from the previously defined server while the latter asks emerge to try to install the prebuilt package first before fetching the sources and compiling it.

For instance, to install gnumeric with prebuilt packages:

root #emerge --usepkg --getbinpkg gnumeric

More information about emerge's prebuilt package options can be found in the emerge man page:

user $man emerge

ビルド済みパッケージを配布する

If prebuilt packages are to be distributed to others, then make sure that this is permitted. Check the distribution terms of the upstream package for this. For example, for a package released under the GNU GPL, sources must be made available along with the binaries.

Ebuilds may define a bindist restriction in their RESTRICT variable if built binaries are not distributable. Sometimes this restriction is conditional on one or more USE flags.

By default, Portage will not mask any packages because of restrictions. This can be changed globally by setting the ACCEPT_RESTRICT variable in /etc/portage/make.conf. For example, to mask packages that have a bindist restriction, add the following line to make.conf:

FILE /etc/portage/make.confOnly accept binary distributable packages
ACCEPT_RESTRICT="* -bindist"

It is also possible to override the ACCEPT_RESTRICT variable by passing the --accept-restrict option to the emerge command. For example, --accept-restrict=-bindist will temporarily mask packages with a bindist restriction.

Also consider setting the ACCEPT_LICENSE variable when distributing packages. See the Licenses section for this.

重要
パッケージのライセンスとそれぞれの国の法律に従うことは、あくまで各 "ユーザー" の責任です。ebuildに書かれたメタデータ変数 (RESTRICTLICENSE) はバイナリ配布の制限などの案内を提供しますが、Portageの出力やGentoo開発者による回答は法的な意味を持つものではなく、これをあてにするべきではありません。お住いの地域の法律に反しないよう、十分に注意してください。

ファイルのフェッチ

Userfetch

Portageがrootとして実行される時、FEATURES="userfetch" を設定しておくことで、パッケージソースを取得するときにroot権限を放棄するようになります。これはちょっとしたセキュリティの向上につながります。

If userfetch is set in FEATURES be sure to change the owner of all the files beneath /usr/portage using the chown command with root privileges:

root #chown --recursive --verbose portage:portage /usr/portage

検証済みのGentooリポジトリスナップショット

Administrators can opt to update the local Gentoo ebuild repository with a cryptographically validated snapshot as released by the Gentoo infrastructure. This ensures that no rogue rsync mirror is adding unwanted code or packages to the repositories the system will be downloading.

Note
The following is an updated method for setting up and using the emerge-webrsync sync method using repos.conf.

The Gentoo release media OpenPGP keys are now available as a binary keyring. These can be installed via the app-crypt/gentoo-keys package:

root #emerge --ask app-crypt/gentoo-keys


FILE /etc/portage/make.confPortage の GPG サポートを有効にする
FEATURES="webrsync-gpg"
PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release"
FILE /etc/portage/repos.conf/gentoo.confClear the sync-uri variable
[DEFAULT]
main-repo = gentoo
 
[gentoo]
# Disable synchronization by clearing the values or setting auto-sync = no
# Do not set value of the variables in this configuration file using quotes ('' or "")!
# For portage-2.2.18 use 'websync'
# For portage-2.2.19 and greater use 'webrsync' (websync was renamed to webrsync)
sync-type = webrsync
sync-uri = 
auto-sync = yes

Make sure that app-crypt/gnupg package is installed:

root #emerge --ask app-crypt/gnupg

Use gpg to verify that the keys in the keyring are the correct keys:

root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --with-fingerprint --list-keys

Verify the fingerprints of the key(s) against those listed on the official Gentoo release engineering project page.

Important
If any of the keys installed from app-crypt/gentoo-keys should expire, run gkeys from app-crypt/gkeys to refresh them from the key server:
root #emerge --ask app-crypt/gkeys
root #gkeys refresh-key -C gentoo

Repeat the following command for each key you wish to trust. (Substitute the keyid '0x...' for the desired key you wish to trust.)

root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --edit-key 0xDB6B8C1F96D8BF6D trust

Should a GPG command-line menu appear, fully trust the key and quit the program by entering the following:

gpg>4
gpg>quit

The system is now set-up to sync using only OpenPGP/gpg verified snapshots.
Several command options are available to perform the sync.

注意
実際に必要になるのは次のコマンドのうち一つだけです。詳細は Portage の sync について書かれたWiki記事 をご覧ください。
root #emerge --sync
root #emaint sync -a
root #emaint sync --repo gentoo
root #emerge-webrsync

Verify distfiles

To re-verify the integrity and (potentially) re-download previously removed/corrupted distfiles for all currently installed packages, run:

root #emerge --ask --fetchonly --emptytree @world




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


ランレベル

システムの起動

システムが起動すると、たくさんのテキストが流れます。注意して見ると、(通常) それが毎回同じ内容であることに気づくでしょう。これら全てのアクションの実行はブートシーケンスと呼ばれ、(ほぼ) 静的に定義されます。

まずブートローダーが、ブートローダーの設定で定義されたカーネルイメージを読み込みます。そしてブートローダーはCPUにカーネルを実行するよう指示します。カーネルが読み込まれ実行されると、全てのカーネル内の構造やタスクが初期化され、initプロセスを開始します。

このプロセスではまず (/etc/fstab に書かれた) すべてのファイルシステムをマウントし、使用可能な状態にします。そして /etc/init.d/ に置かれたいくつかのスクリプトを実行します。これらのスクリプトは、システムのブートに必要なサービスを立ち上げます。

全てのスクリプトを実行したら、initは最後に端末 (ほとんどの場合 Alt+F1Alt+F2 などの下に隠された仮想端末ですが) を agetty と呼ばれる特別なプロセスに接続します。このプロセスは login を実行することで各端末からユーザーがログオンできるようにします。

Initscripts

ところで、initは /etc/init.d/ 内のスクリプトを適当に実行するわけではありません。それどころか、/etc/init.d/ 内のスクリプトを全て実行するわけでもなく、指示されたスクリプトだけを実行します。実行するスクリプトは /etc/runlevels/ を見て決定しています。

まずinitは /etc/init.d/ にあるスクリプトのうち、/etc/runlevels/boot/ にシンボリックリンクが存在するものを全て実行します。基本的にはアルファベット順に開始しますが、一部のスクリプトは自身の前に開始しなければならないスクリプトを示す依存情報を持っています。

/etc/runlevels/boot/ から参照されている全てのスクリプトを実行すると、続けてinitは /etc/runlevels/default/ にシンボリックリンクが存在するスクリプトを実行します。繰り返しになりますが、正しい起動シーケンスのために順序を変更する依存情報をスクリプトが持っていない限り、アルファベット順でスクリプトの実行順が決まります。これは Gentoo Linux のインストールで実行した rc-update add sshd default などのコマンドで default を使った理由でもあります。

init の仕組み

もちろん、init 自身がこれらすべてを決定するわけではありません。どのような動作をすべきか指定する設定ファイルが必要です。この設定ファイルが /etc/inittab です。

先ほど説明したブートシーケンスを思い出してください - init が最初にする動作はすべてのファイルシステムをマウントすることです。これは /etc/inittab の以下の行で定義されています:

FILE /etc/inittab初期化コマンド
si::sysinit:/sbin/openrc sysinit

この行は init に対し、システムを初期化するために /sbin/openrc sysinit を実行するよう指示します。/sbin/openrc スクリプトが初期化を処理するので、init はあまり多くのことをしないと言えるかもしれません - システム初期化のタスクは他のプロセスに委譲しているのです。

第二に、init は /etc/runlevels/boot/ にシンボリックリンクがあるすべてのスクリプトを実行します。これは以下の行で定義されています:

FILE /etc/inittabブートコマンドの実行
rc::bootwait:/sbin/openrc boot

再び openrc スクリプトが必要なタスクを処理します。openrc に渡されるオプション(boot)が、使用する /etc/runlevels/ のサブディレクトリと同じであることに注目してください。

ここで、init はどのランレベルを実行すべきか見るために設定ファイルを調べます。これを決定するために /etc/inittab から以下の行が読み込まれます:

FILE /etc/inittabデフォルトランレベルの選択
id:3:initdefault:

この場合(Gentoo ユーザーの多くはこれを使用しています)、ランレベルの id は3です。この情報を使って、init はランレベル3を開始するために何を実行する必要があるかを調べます:

FILE /etc/inittabランレベルの定義
l0:0:wait:/sbin/openrc shutdown
l1:S1:wait:/sbin/openrc single
l2:2:wait:/sbin/openrc nonetwork
l3:3:wait:/sbin/openrc default
l4:4:wait:/sbin/openrc default
l5:5:wait:/sbin/openrc default
l6:6:wait:/sbin/openrc reboot

レベル3を定義している行では、サービスを開始するために再度 openrc を(今度は引数 default とともに)使用しています。今回も openrc の引数が /etc/runlevels/ のサブディレクトリと同じであることに注目してください。

openrc が終了すると、init はどの仮想コンソールを有効化すべきか、また各コンソールでどのコマンドを実行しなければならないかを決定します:

FILE /etc/inittabターミナルの定義
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

有効なランレベル

前の節では、init がどのランレベルを有効化するか決めるために番号を用いていることを説明しました。ランレベルはシステムが動作する際の状態であり、ランレベルを開始したり終了したりした時に実行されるスクリプト(ランレベルスクリプトあるいは init スクリプト)の一群を含んでいます。

Gentoo では7つのランレベルが定義されています: 3つの内部ランレベルと4つのユーザー定義ランレベルです。内部ランレベルはそれぞれ sysinitshutdown そして reboot と呼ばれており、まさに名前が示す通りに動作します: システムの初期化、システムのパワーオフ、そしてシステムの再起動を行うのです。

ユーザー定義ランレベルはそれぞれ付随する /etc/runlevels/ のサブディレクトリーを持ちます: bootdefaultnonetwork そして single です。boot ランレベルは、他のランレベルによって使用される、システムに必要なすべてのサービスを起動します。残りの3つのランレベルは開始するサービスに違いがあります: default は日常的な作業に使われ、nonetwork は一切のネットワーク接続が不要な場合に使われ、そして single はシステムを修復する必要がある時に使われます。

init スクリプトの使い方

openrc プロセスが開始するスクリプトは init スクリプトと呼ばれます。/etc/init.d/ 内の各スクリプトは startstoprestartzapstatusineediuseiwantneedsmeusesme あるいは wantsme という引数で実行することができます。

サービス(およびすべての依存サービス)を開始、停止、あるいは再起動するには、startstop および restart 引数を使います:

root #/etc/init.d/postfix start
Note
指定されたサービスを必要(need)とするサービスのみが停止または再起動されます。その他の依存サービス(指定されたサービスを使用(use)するが必要(need)としないもの)は影響されません。

あるサービスを停止するが依存サービスは停止させたくない場合には、stop 引数とともに --nodeps オプションも使用します:

root #/etc/init.d/postfix --nodeps stop

サービスがどのような状態にあるか(started、stopped、 ...)見るには status 引数を使用します:

root #/etc/init.d/postfix status

サービスが実行中であるというステータス情報が表示されたのに実際はそうでない場合には、zap 引数を使用してステータス情報を "stopped" にリセットします:

root #/etc/init.d/postfix zap

サービスがどのような依存関係を持っているか問い合わせるには、iwantiuse あるいは ineed 引数を使用します。ineed を使うとそのサービスが正しく機能するために本当に必要なサービスが表示されます。一方 iwantiuse は、そのサービスから使用することができるけれども、正しく機能する上で必要というわけではないサービスを表示します。

root #/etc/init.d/postfix ineed

同じように、そのサービスを必要としているサービス(needsme)やそのサービスを使用できるサービス(usesme または wantsme)を問い合わせることもできます:

root #/etc/init.d/postfix needsme

ランレベルの更新

rc-update

Gentoo の init システムはまずどのサービスを開始する必要があるかを決めるために依存関係ツリーを使用しています。これはユーザーに手動でやってもらうには退屈な作業なので、ランレベルや init スクリプトの管理を簡略化するツールが作成されました。

rc-update を使って init スクリプトをランレベルに追加したり削除することができます。rc-update ツールはその後自動的に depscan.sh スクリプトを使って依存関係ツリーを再構築します。

サービスの追加と削除

これまでの説明では init スクリプトはすでに "default" ランレベルに追加されていました。"default" の意味するところはこの文書の前の方で説明しました。ランレベルの他に、rc-update スクリプトは動作を定義する第二の引数を必要とします: adddel または show です。

init スクリプトを追加または削除するには、rc-updateadd または del 引数、その後に init スクリプトとランレベルを渡します。一例:

root #rc-update del postfix default

rc-update -v show コマンドは利用可能なすべての init スクリプトと、それらが実行されるランレベルの一覧を出力します:

root #rc-update -v show

rc-update show を(-v 引数なしで)実行して有効になっている init スクリプトとそのランレベルのみを表示させることもできます。

サービスの設定

追加の設定が必要な理由

init スクリプトはとても複雑です。したがって、ユーザーに init スクリプトを直接編集してもらうのは間違いを起こしやすくなり必ずしも合理的ではありません。しかしながら、サービスを設定できるということは重要です。たとえば、ユーザーがサービス自体により多くのオプションを渡したい場合があるでしょう。

init スクリプトの外部に設定を持つ第二の理由は、ユーザーの設定変更を取り消してしまうおそれなしに init スクリプトを更新できるということです。

conf.d ディレクトリ

Gentoo はこうしたサービスを設定する簡単な方法を提供しています: 設定可能なすべての init スクリプトは /etc/conf.d/ にファイルを持ちます。たとえば、apache2 init スクリプトは /etc/conf.d/apache2 という設定ファイルを持っており、これには Apache2 サーバーに起動時に渡すオプションを含めることができます:

FILE /etc/conf.d/apache2apache2 init スクリプト用のオプションの例
APACHE2_OPTS="-D PHP5"

こうした設定ファイルは(/etc/portage/make.conf のように)変数のみ を含んでおり、サービスの設定を非常に容易にします。また、これにより変数について(コメントとして)より多くの情報を提供できるようになっています。

initスクリプトを書く

これは必要な作業なんですか?

いいえ、Gentoo は提供しているすべてのサービスについてそのまま使える init スクリプトを提供しているので、通常は init スクリプトを書く必要はありません。しかしながら、一部のユーザーは Portage を使わずにサービスをインストールしているかもしれません。このような場合にはたいてい init スクリプトを作成しなければなりません。

サービスによって提供されている init スクリプトは、明示的に Gentoo 用に書かれているのでなければ使用してはいけません: Gentoo の init スクリプトは他のディストリビューションで使われている init スクリプトとは互換性がありません! そのディストリビューションが OpenRC を使っているのでない限りは、ということですが!

レイアウト

init スクリプトの基本構造は以下の通りです。

CODE (伝統的な) init スクリプトのレイアウト例
#!/sbin/openrc-run
  
depend() {
#  (Dependency information)
}
  
start() {
#  (Commands necessary to start the service)
}
  
stop() {
#  (Commands necessary to stop the service)
}
CODE Example initscript layout (updated)
#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="FooBar Daemon"

description="FooBar is a daemon that drinks"
extra_started_commands="drink"
description_drink="Opens mouth and reflexively swallows"

depend() {
#  (Dependency information)
}

start_pre() {
#  (Commands necessary to prepare to start the service)
    # Ensure that our dirs are correct
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commands necessary to clean up after the service)
    # Clean any spills
    rm -rf /var/cache/foo/*
}

drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

すべての init スクリプトは start() 関数または command 変数を必要とします。それ以外のすべての部分は任意です。

依存関係

init スクリプトの開始や順位付けに影響する、依存関係によく似た3つの設定が定義できます: wantuse および need です。さらに、順番に影響する2つのメソッド beforeafter もあります。最後の2つは本来依存関係ではありません - 選択されたサービスの開始がスケジュールされていない場合(または開始に失敗した場合)でも、もとの init スクリプトは失敗しないのです。

  • use の設定は、このスクリプトが選択されたスクリプトによって提供される機能を使う(use)ものの、それに直接は依存していないことを init システムに対し通知します。use loggeruse dns が良い例です。これらのサービスが利用可能なら活用しますが、システムにロガーや DNS サーバーがなくてもサービスは動作します。(訳註: use で指定された)サービスが存在する場合、それらはその機能を使用するスクリプトの前に開始されます。
  • want の設定は1つの例外を除いて use と同じです。use は init レベルに追加されたサービスのみを考慮します。want は init レベルに追加されていなくても、利用可能なサービスを起動しようとします。
  • need は強い依存関係です。つまり、他のスクリプトを必要とする(need)スクリプトはその(訳註: 必要とされている)スクリプトが正常に開始されるより前には開始できません。また、その(訳註: 必要とされている)スクリプトが再起動される場合にはこの(訳註: 必要としている)スクリプトも再起動されます。
  • before を使用した場合、そのスクリプトは、選択されたスクリプトが init レベルに含まれていればそれよりも前に起動されます。before alsasound を定義している xdm という init スクリプトは、alsasound が同じ init レベルで開始されるようにスケジュールされている場合に限り、alsasound スクリプトよりも前に開始されます。alsasound の開始がスケジュールされていない場合はこの設定には効果がなく、xdm は init システムが最も適切とみなす時に開始されます。
  • 同様に after はそのスクリプトが、選択されたスクリプトが init レベルに含まれている場合にはその後に起動されるべきであることを init システムに対し通知します。選択されたスクリプトが init レベルに含まれていない場合にはこの設定には効果がなく、そのスクリプトは init システムが最も適切とみなす時に開始されます。

ここから分かるように、need はスクリプトが開始されるかどうかに影響を与えるので、これが唯一の"真の"依存関係の設定です。それ以外はすべて、スクリプトがどのような順番で起動できるか(あるいはされるべきか)を明確にするための init システムに対する助言に過ぎません。

さて、Gentoo で利用可能なたくさんの init スクリプトを見てみると、そのいくつかに init スクリプトでないものへの依存関係があることに気がつきます。これらの"もの"を virtual と呼びます。

virtual 依存は、あるサービスが提供しているものの、そのサービスのみによって提供されているわけではない依存関係です。init スクリプトはシステムロガーに依存することができますが、利用可能なシステムロガーは数多くあります(metalogd、syslog-ng、sysklogd、 ...)。スクリプトはこれらのどれか一つを必要とする(need)ことはできません(実用的なシステムにおいて、これらのシステムロガーすべてがインストールされ実行されているということはありません)から、これらのサービスすべてで virtual 依存を必ず提供するようにしています。

一例として、postfix の依存情報を見てみましょう:

FILE /etc/init.d/postfixpostfix サービスの依存情報
depend() {
  need net
  use logger dns
  provide mta
}

表示されているように、postfix サービスは:

  • (virtual) net (これはたとえば /etc/init.d/net.eth0 によって提供されます)を必要とします。
  • (virtual) logger (これはたとえば /etc/init.d/syslog-ng によって提供されます)を使用(use)します。
  • (virtual) dns (これはたとえば /etc/init.d/named によって提供されます)を使用(use)します。
  • (virtual) mta (これはすべてのメールサーバーに共通です)を提供します。

順序の制御

前の節で説明しているように、init システムにスクリプトを開始(または停止)するのに使用する順序を指示することができます。この順序は use および need という依存関係の設定を介してだけでなく、before および after という順序の設定によっても扱うことができます。前者についてはすでに説明しましたから、こうした init スクリプトの例として portmap サービスを見てみましょう。

FILE /etc/init.d/portmapportmap サービスの依存情報
depend() {
  need net
  before inetd
  before xinetd
}

同じランレベルのすべてのサービスを表す "*" グロブを使うこともできますが、これは推奨されません。

CODE * グロブの使用
depend() {
  before *
}

サービスがローカルディスクに書き込む必要があるなら、localmount を need にするべきです。サービスが /var/run/ に pidfile といったものを配置する場合は bootmisc の後(after)に起動すべきです。

CODE need localmount、after bootmisc とした依存設定
depend() {
  need localmount
  after bootmisc
}

標準関数

depend() 関数に続いて、start() 関数も定義する必要があります。これにはサービスを初期化するために必要なすべてのコマンドが含まれています。ユーザーに何が起きているか通知するため ebegin および eend 関数を使用することをお勧めします:

CODE start() 関数の例
start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Do something in case a restart requires more than stop, start
  fi
  
  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

start と stop 関数では、--exec--pidfile の両方を使用すべきです。サービスが pidfile を作成しない場合は、それを確かめるためにテストすることが推奨されますが、可能であれば --make-pidfile を使ってください。そうでなければ、pidfile を使用しないようにします。また、start-stop-daemon のオプションに --quiet を追加することもできますが、サービスが極めて詳細な出力をする場合以外にはお勧めしません。--quiet はサービスの開始が失敗する場合にデバッグを妨げることがあります。

上の例の中で注目すべきもう一つの設定は RC_CMD 変数の内容のチェックです。以前の init スクリプトシステムとは異なり、新しい OpenRC システムはスクリプト特有の再起動機能をサポートしていません。代わりに、スクリプトは関数(start()stop())が再起動の一環として呼ばれたのかどうか知るために RC_CMD 変数の内容を調べる必要があります。

Note
--exec がサービスを実際に起動しており、サービスを起動して終了するシェルスクリプトを単に呼び出しているのではないことを確認してください - それは init スクリプトがすべきことです。

start() 関数の更なる例については、/etc/init.d/ ディレクトリーで利用可能な init スクリプトのソースコードを読んでください。

もう一つの定義できる(が必須ではない)関数が stop() です。init システムは start-stop-daemon が使用されている場合にはこの関数を自身で補うことができます。

CODE stop() 関数の例
stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

サービスが他のスクリプト(たとえば Bash、Python あるいは Perl など)を実行し、かつこのスクリプトの名前が後で変わる場合(たとえば foo.py が foo になるなど)には、start-stop-daemon に --name を加える必要があります。これにはスクリプトの変更後の名前を指定しなければなりません。この例では、サービスは foo.py を実行し、その名前が foo に変わります:

CODE foo スクリプトを開始するサービスの定義例
start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

start-stop-daemon は、より多くの情報が必要になった際に利用可能な素晴らしい man ページを備えています:

user $man start-stop-daemon

Gentoo の init スクリプトの文法は POSIX シェルをもとにしているので、init スクリプトの中で sh 互換の構文を使うことができます。Gentoo がもし init システムに変更を加えてもスクリプトが機能し続けるようにするために、それ以外の構文、たとえば bash 特有のものなどは init スクリプトに含めないでください。

カスタムオプションの追加

init スクリプトがこれまでに見たもの以外のオプションをサポートする必要がある場合、そのオプションを以下の変数のうちの一つに追加し、オプションと同名の関数を作成してください。たとえば restartdelay というオプションをサポートするには:

  • extra_commands - コマンドはすべての状態のサービスにおいて利用可能です
  • extra_started_commands - コマンドはサービスが開始済み(started)の時に利用可能です。
  • extra_stopped_commands - コマンドはサービスが停止中(stopped)の場合に利用可能です


CODE restartdelay メソッドの定義例
extra_started_commands="restartdelay"
  
restartdelay() {
  stop
  sleep 3    # Wait 3 seconds before starting again
  start
}
Important
OpenRC では restart() 関数を上書きすることはできません!

サービス設定変数

/etc/conf.d/ の設定ファイルをサポートするために詳細な実装をする必要はありません: init スクリプトが実行される際には以下のファイルが自動的に読み込まれます(つまり、変数が利用可能になります):

  • /etc/conf.d/YOUR_INIT_SCRIPT
  • /etc/conf.d/basic
  • /etc/rc.conf

また、init スクリプトが virtual 依存(net など)を提供している場合、その依存と関連付けられているファイル(/etc/conf.d/net など)も読み込まれます。

ランレベルの動きを変える

これが役に立つ人

多くのラップトップユーザーはこうした状況を経験したことがあるでしょう: 自宅では net.eth0 を開始する必要があるけれど、移動中は(使えるネットワークがないので) net.eth0 を開始してほしくない。Gentoo ではランレベルの動作を意のままに変更できます。

たとえば、異なる init スクリプトが割り当てられた第二の起動可能な "default" ランレベルを作成することができます。こうすれば、ユーザーはブート時にどのデフォルトランレベルを使用するか選択できます。

softlevel を使う

まず最初に、第二の "default" ランレベル用のランレベルディレクトリーを作成します。一例として、offline ランレベルを作成します:

root #mkdir /etc/runlevels/offline

新しく作成したランレベルに必要な init スクリプトを追加します。たとえば、net.eth0 以外は現在のデフォルトランレベルを完全にコピーするには:

root #cd /etc/runlevels/default
root #for service in *; do rc-update add $service offline; done
root #rc-update del net.eth0 offline
root #rc-update show offline
(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

offline ランレベルから net.eth0 は削除されましたが、それでも udev は自身が検出したすべてのデバイスを開始して適切なサービスを起動しようとするかもしれません。これはホットプラグと呼ばれる機能です。デフォルトでは、Gentoo はホットプラグを有効化していません。

選択したいくつかのスクリプトのみについてホットプラグを有効にするには、/etc/rc.confrc_hotplug 変数を使います:

FILE /etc/rc.confWLAN インターフェースのホットプラグを有功にする
rc_hotplug="net.wlan !net.*"
Note
デバイスによって開始されるサービスについての詳細は /etc/rc.conf 内のコメントを見てください。

ブートローダーの設定を編集し、offline ランレベル用の新しい項目を追加します。この項目では、softlevel=offline をブートパラメーターとして追加します。

bootlevel を使う

bootlevel を使用する場合も softlevel とよく似ています。唯一の違いは、この場合は第二の "default" ランレベルではなく第二の "boot" ランレベルが定義されることです。




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


環境変数

はじめに

An environment variable is a named object that contains information used by one or more applications. By using environment variables one can easily change a configuration setting for one or more applications.

Important examples

The following table lists a number of variables used by a Linux system and describes their use. Example values are presented after the table.

Variable Description
PATH This variable contains a colon-separated list of directories in which the system looks for executable files. If a name is entered of an executable (such as ls, rc-update, or emerge) but this executable is not located in a listed directory, then the system will not execute it (unless the full path is entered as the command, such as /bin/ls).
ROOTPATH This variable has the same function as PATH, but this one only lists the directories that should be checked when the root-user enters a command.
LDPATH This variable contains a colon-separated list of directories in which the dynamical linker searches through to find a library.
MANPATH This variable contains a colon-separated list of directories in which the man command searches for the man pages.
INFODIR This variable contains a colon-separated list of directories in which the info command searches for the info pages.
PAGER This variable contains the path to the program used to list the contents of files through (such as less or more).
EDITOR This variable contains the path to the program used to change the contents of files with (such as nano or vi).
KDEDIRS This variable contains a colon-separated list of directories which contain KDE-specific material.
CONFIG_PROTECT This variable contains a space-delimited list of directories which should be protected by Portage during updates.
CONFIG_PROTECT_MASK This variable contains a space-delimited list of directories which should not be protected by Portage during updates.

Below is an example definition of all these variables:

CODE Example settings for the mentioned variables
PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf"

Defining variables globally

env.d ディレクトリー

To centralize the definitions of these variables, Gentoo introduced the /etc/env.d/ directory. Inside this directory a number of files are available, such as 00basic, 05gcc, etc. which contain the variables needed by the application mentioned in their name.

For instance, when gcc is installed, a file called 05gcc was created by the ebuild which contains the definitions of the following variables:

FILE /etc/env.d/05gccDefault gcc enabled environment variables
PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info"
CC="gcc"
CXX="g++"
LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

Other distributions might tell their users to change or add such environment variable definitions in /etc/profile or other locations. Gentoo on the other hand makes it easy for the user (and for Portage) to maintain and manage the environment variables without having to pay attention to the numerous files that can contain environment variables.

For instance, when gcc is updated, the /etc/env.d/05gcc file is updated too without requesting any user-interaction.

This not only benefits Portage, but also the user. Occasionally users might be asked to set a certain environment variable system-wide. As an example we take the http_proxy variable. Instead of messing about with /etc/profile, users can now just create a file (say /etc/env.d/99local) and enter the definition(s) in it:

FILE /etc/env.d/99localSetting a global variable
http_proxy="proxy.server.com:8080"

By using the same file for all self-managed variables, users have a quick overview on the variables they have defined themselves.

env-update

Several files in /etc/env.d/ define the PATH variable. This is not a mistake: when the env-update command is executed, it will append the several definitions before it updates the environment variables, thereby making it easy for packages (or users) to add their own environment variable settings without interfering with the already existing values.

The env-update script will append the values in the alphabetical order of the /etc/env.d/ files. The file names must begin with two decimal digits.

CODE Update order used by env-update
00basic        99kde-env       99local
     +-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

The concatenation of variables does not always happen, only with the following variables: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH, and PYTHONPATH. For all other variables the latest defined value (in alphabetical order of the files in /etc/env.d/) is used.

It is possible to add more variables into this list of concatenate-variables by adding the variable name to either COLON_SEPARATED or SPACE_SEPARATED variables (also inside an /etc/env.d/ file).

When executing env-update, the script will create all environment variables and place them in /etc/profile.env (which is used by /etc/profile). It will also extract the information from the LDPATH variable and use that to create /etc/ld.so.conf. After this, it will run ldconfig to recreate the /etc/ld.so.cache file used by the dynamical linker.

To notice the effect of env-update immediately after running it, execute the following command to update the environment. Users who have installed Gentoo themselves will probably remember this from the installation instructions:

root #env-update && source /etc/profile
Note
The above command only updates the variables in the current terminal, new consoles, and their children. Thus, if the user is working in X11, he needs to either type source /etc/profile in every new terminal opened or restart X so that all new terminals source the new variables. If a login manager is used, it is necessary to become root and restart the /etc/init.d/xdm service.
Important
It is not possible to use shell variables when defining other variables. This means things like FOO="$BAR" (where $BAR is another variable) are forbidden.

Defining variables locally

User specific

It might not be necessary to define an environment variable globally. For instance, one might want to add /home/my_user/bin and the current working directory (the directory the user is in) to the PATH variable but do not want all other users on the system to have that in their PATH too. To define an environment variable locally, use ~/.bashrc or ~/.bash_profile:

FILE ~/.bashrcExtending PATH for local usage
# A colon followed by no directory is treated as the current working directory
PATH="${PATH}:/home/my_user/bin:"

After logout/login, the PATH variable will be updated.

Session specific

Sometimes even stricter definitions are requested. For instance, a user might want to be able to use binaries from a temporary directory created without using the path to the binaries themselves or editing ~/.bashrc for the short time necessary.

In this case, just define the PATH variable in the current session by using the export command. As long as the user does not log out, the PATH variable will be using the temporary settings.

root #export PATH="${PATH}:/home/my_user/tmp/usr/bin"




Warning: Display title "Gentoo Linux amd64 ハンドブック:Gentoo での作業" overrides earlier display title "ハンドブック:AMD64/フル/ワーキング".