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

This page is a translated version of the page Handbook:AMD64/Full/Working and the translation is 100% complete.

Portage へようこそ

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

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

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

user $man emerge

Gentoo リポジトリ

Ebuild

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

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

Gentoo リポジトリの更新

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

root #emerge --sync

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

root #emerge-webrsync

ソフトウェアを保守する

ソフトウェアの検索

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

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

user $emerge --search pdf

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

user $emerge --searchdesc pdf

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

コード 検索コマンドの出力例

*  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

上と同じことをしつつ、インストールを続行するかどうか対話的に選択するには、--ask フラグを追加してください:

root #emerge --ask gnumeric

パッケージのインストールの過程で、Portageは(必要なら)ソースコードをインターネット上からダウンロードし、デフォルトでは /var/cache/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 --deselect を使います。これは Portage に、パッケージがもう必要でないので、--depclean によるクリーンアップの対象であることを伝えます。

root #emerge --deselect gnumeric

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

システムの更新

システムをきれいに保つため (そしてもちろん最新のセキュリティアップデートを適用するため) には、日常的にシステムを更新する必要があります。Portage は Gentoo リポジトリに入っている ebuild しか確認しませんから、最初にすることは emerge --sync を使用してリポジトリを更新することです。そして、emerge --deep --update @world でシステムを更新することができます。

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

root #emerge --update --deep @world

標準的なアップグレードコマンドは、リポジトリのプロファイル内に変更がある可能性から、またはシステム USE 設定が変更されている場合のために、--changed-use または --newuse を含むべきです。これにより、その変更に新しいパッケージのインストールや既存パッケージの再コンパイルが必要でないかどうか、Portage が調べてくれます。

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

メタパッケージ

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

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

Portageは、孤独な依存関係を削除する機能も備えています。しかし、ソフトウェアの可用性は動的依存のため、まずシステム全体を完全にアップデートすることが重要です。これにはUSEフラグの変更が適用された新しい変更も含みます。これの後、emerge --depcleanを実行し、孤独な依存関係を削除することが出来ます。これが完了したら、今削除されたソフトウェアと動的にリンクしていたが、もはやそのソフトウェアを必要としないアプリケーションの再ビルドが必要かもしれません。尤も、最近このサポートはPortageに追加されましたが。

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

root #

emerge --update --deep --newuse @world

root #

emerge --ask --depclean

ライセンス

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

重要
免責事項および法的な責任の境界として、ebuild の LICENSE 変数は Gentoo の開発者やユーザにとっての単なるガイドラインです。これは法的な声明でも、ebuild によってインストールされるすべてのファイルのライセンスを反映していることの保証でもありません。パッケージによって提供されるすべてのファイルの完全に正確な法的表現として信頼するべきではありません。確証を得るためには、システム管理者はパッケージによってインストールされるすべてのファイルについて、適切なライセンスの連携と準拠がされているか、掘り下げてチェックするべきです。もし ebuild に食い違いを見つけた場合は、その ebuild の LICENSE 変数に割り当てられた値の変更を提案するために、バグを提出してください。

Portage はデフォルトでは、フリーソフトウェア財団、Open Source Initiativeによって明示的に承認されたライセンス、あるいは自由ソフトウェアの定義に従っているライセンスを許可します。

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

ファイル /etc/portage/make.confデフォルトのACCEPT_LICENSE設定

ACCEPT_LICENSE="-* @FREE"

この設定の下では、自由ソフトウェアライセンスあるいは自由な文書ライセンスが設定されているパッケージがインストール可能となります。フリーではないソフトウェアはインストールできなくなります。

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

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

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

www-client/google-chrome google-chrome

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

または、よく必要になる sys-kernel/linux-firmware を許可するには:

ファイル /etc/portage/package.licenselinux-firmware パッケージに関してライセンスを受諾する

# linux-firmware に関してライセンスを受諾する
sys-kernel/linux-firmware linux-fw-redistributable

# 再配布を許可するすべてのライセンスを受諾する
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

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

ACCEPT_LICENSE 変数内で定義されるライセンスグループは @ 記号で始まります。ありうる（かつてPortageのデフォルトだった）設定は、使用許諾契約書を読み同意する必要があるEnd User License Agreements（使用許諾契約、EULA）を除いてすべてのライセンスを受諾する設定です。これを実現するには、次のように、現在許可されているすべてのライセンスを受諾し（*を使います）、その後 EULA グループ内のライセンスのみを受諾取り消ししてください:

ファイル /etc/portage/make.confEULAを除くすべてのライセンスを受諾する

ACCEPT_LICENSE="* -@EULA"

この設定は、フリーではないソフトウェアや文書も受諾する事に注意してください。

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

用語について

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

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

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

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

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

それぞれのGentooインストールは、システムが通常通り機能するために必要な、パッケージのリストを含む情報を格納している特定のプロファイルに従っています。

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

コード ブロックされたパッケージについての Portage の警告

[ebuild  N     ] x11-wm/i3-4.20.1  USE="-doc -test"
[blocks B      ] x11-wm/i3 ("x11-wm/i3" is soft blocking x11-wm/i3-gaps-4.20.1)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
    x11-wm/i3

  (x11-wm/i3-gaps-4.20.1-1:0/0::gentoo, installed) pulled in by
    x11-wm/i3-gaps required by @selected

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

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

ユーザはブロックを解決するために、そのパッケージをインストールしないか、コンフリクトしているパッケージを先に unmerge するかを選ぶことができます。上の例でいえば、x11-wm/i3 のインストールをやめるか、先に x11-wm/i3-gaps を取り除くか選べます。通常は、例えば emerge --deselect x11-wm/i3-gaps のようにして単に Portage にそのパッケージはもう希望しないと伝え、パッケージ自体を強制的に除去するのではなく world ファイルから削除するのがベストです。

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

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

マスクされたパッケージ

コード マスクされたパッケージについての Portage の警告

!!! all ebuilds that could satisfy "bootsplash" have been masked.

コード マスクされたパッケージについての 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	アプリケーションはターゲットアーキテクチャ上で動作しません。これが正しくなければ、バグを提出してください。
missing keyword	アプリケーションはまだターゲットアーキテクチャ上でテストされていません。アーキテクチャ移植チームにパッケージのテストを依頼するか、彼らのためにテストして Gentoo の Bugzilla のウェブサイトで知見を報告してください。/etc/portage/package.accept_keywords および特定のパッケージに対してキーワードを許可するも参照してください。
package.mask	パッケージが破損している、不安定、あるいはもっと悪い状態であると判明したため、意図的に「使用禁止」としてマークされています。
profile	パッケージは現在のプロファイルに適していないことが判明しています。アプリケーションをインストールするとシステムが壊れるか、単に現在使用中のプロファイルと互換性がありません。
license	パッケージのライセンスが `ACCEPT_LICENSE` の値に適合していません。/etc/portage/make.conf または /etc/portage/package.license で設定して、ライセンスまたは正しいライセンスグループを許可してください。

USE フラグの変更が必要

コード 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 がセットされていないと、次のようなエラーメッセージも表示されるかもしれません:

コード 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 内で特定のパッケージに対してセットしてください。

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

コード 依存パッケージの不在についての 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 名

コード あいまいな 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 は何から選べばいいか、マッチしたものを教えてくれるでしょう。

循環依存

コード 循環依存についての 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 をチェックしてこの問題が既知のものであるか確認し、そうでなければ報告することも有益でしょう。

フェッチ失敗

コード フェッチ失敗についての Portage の警告

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

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

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

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

コード プロファイルによって保護されているパッケージについての Portage の警告

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

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

ダイジェスト検証失敗

コード ダイジェスト検証失敗

>>> checking ebuild checksums
!!! Digest verification failed:

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

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

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

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

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

← インストールの締めくくり Home USE フラグ →

USE フラグとは何ですか

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

Gentoo をインストールするとき、ユーザーは自らが扱う環境に応じて選択を行います。サーバー向けのセットアップは、ワークステーション向けのセットアップとは異なります。ゲーミングワークステーションと、3D レンダリングワークステーションは違います。

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

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

USE フラグの定義

USE フラグを入力しましょう。このフラグは、あるコンセプトに対するサポートと依存の情報を表すキーワードです。ある USE フラグが有効として設定されると、Portage はシステム管理者が選択されたキーワードに関するサポートを求めていることを知ることになります。当然、これによってパッケージへの依存の情報も変更される場合があります。USE フラグに応じて、要求された依存関係の変更を満たすために、より多くの依存パッケージを入れる必要があるかもしれません。

具体例を見てみましょう: kde USE フラグ。このフラグが USE 変数に設定されていない (または -kde と値の前にマイナス記号が付いている) とき、オプションで KDE をサポートしているすべてのパッケージは、KDE サポートなしでコンパイルされます。オプションで KDE に依存しているすべてのパッケージは、KDE のライブラリを(依存先として)インストールせずにインストールされます。

もし kde フラグが有効化されているならば、これらのパッケージはKDE サポートありでコンパイルされ、KDE のライブラリも依存先としてインストールされることになります。

的確に USE フラグを定義することで、システムはシステム管理者の具体的な必要に合わせて仕立てられることになります。

USE フラグを使う

永続的な USE フラグの宣言

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

システムが従うプロファイルは、 /etc/portage/make.profile symlinkが指し示す先にあります。それぞれのプロファイルは他のプロファイルの上で働くため、結果は全てのプロファイルの合計ということになります。トップのプロファイルはbaseプロファイルです(/var/db/repos/gentoo/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で定義できます:

ファイル /etc/portage/make.confmake.conf 内の USE フラグを更新する

USE="-kde -qt5 ldap"

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

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

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

ファイル /etc/portage/package.useVLC の Blu-ray サポートを有効にする

media-video/vlc bluray

ヒント
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フラグ設定を通じて有効にする)には:

ファイル /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設定の優先順位は、優先度順に(優先度が低いものから)並べると、次のようになっています:

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

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

root #emerge --info

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

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

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

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

重要
提供される"不要になった"パッケージの一覧をダブルチェックし、必要なパッケージが削除されないことを確認してください。次の例では、--pretend (-p) スイッチを追加して、depclean がパッケージの一覧表示のみを行い、削除を行わないようにしています:

root #emerge --pretend --depclean

depcleanが完了したらemerge は、削除されたかもしれないパッケージが提供していた共有オブジェクトに対して動的リンクされていたアプリケーションをリビルドするよう促すかもしれません。Portageはアプリケーションを破壊するのを防ぐため、このアクションが取られるまで必要なライブラリを保存します。Portageはリビルドが必要なものをpreserved-rebuildセットに登録します。必要なパッケージをリビルドするためには、次のコマンドを実行してください：

root #emerge @preserved-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

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

user $equery --nocolor uses =app-portage/portage-utils-0.93.3

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-portage/portage-utils-0.93.3:
 U I
 + + nls       : Add Native Language Support (using gettext - GNU locale utilities)
 + + openmp    : Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE="openmp"
 + + qmanifest : Build qmanifest applet, this adds additional dependencies for GPG, OpenSSL and BLAKE2B hashing
 + + qtegrity  : Build qtegrity applet, this adds additional dependencies for OpenSSL
 - - static    : !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically

REQUIRED_USE 条件を満足させる

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

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

← Portageについて Home Portageの機能 →

Portage の機能

Portageは、Gentooでの体験を更により良くする追加の機能をいくつか備えています。これらの機能の多くは、パフォーマンス、信頼性、セキュリティなどを向上させる、あるソフトウェアツールに依存しています。

Portageのある特定の機能を有効あるいは無効にするには、/etc/portage/make.confを編集し、様々な、機能に関するキーワードをスペース区切りで格納するFEATURES変数に値を設定、あるいは値を更新してください。一部の場合では、その機能が依存する追加のツールもインストールする必要があります。

Portageがサポートするすべての機能がここに一覧として表示されているわけではありません。全体を概観するには、make.confのmanページを参照してください。

user $man make.conf

デフォルトでFEATURES変数に何が設定されているかを確認するには、emerge --infoを実行し、FEATURESの項を探すかgrepしてください。

user $emerge --info | grep ^FEATURES=

分散コンパイル

distcc を使う

distccは、ネットワーク上のいくつかの（必ずしも同一ではない）マシンにコンパイルを分散させるプログラムです。distccのクライアントはすべての必要な情報を、利用可能な（distccdが稼働している）distccサーバに送ります。これによってクライアントのためにソースコードの一部分をコンパイルできます。最終的に、より早くコンパイルすることが出来ます。

distcc について (そしてそれをどのように Gentoo で機能させるかについて) のさらなる情報は、Distcc のページにあります。

distcc のインストール

distcc には、コンパイルのためにコンピュータが送信しているタスクを監視するグラフィカルモニタが付属しています。このツールは USE="gtk" が設定されていると自動的にインストールされます。

root #emerge --ask sys-devel/distcc

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

distccを/etc/portage/make.conf内のFEATURES変数に追加してください。次に、MAKEOPTS変数を編集し、システムが許可する並行ビルドジョブの数を増やしてください。知られているガイドラインとして、Nを、distccdが稼働しているCPUの数（現在のホストも含む）に1を加えたものとして、-jNを指定することです。ただし、これはあくまでガイドラインです。

それではdistcc-configを実行し、利用できるdistccのサーバを入力してください。単純な例として、利用可能なdistccのサーバが、192.168.1.102（現在のホスト）、192.168.1.103そして192.168.1.104（2つの"リモートの"ホスト）であるとします：

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

distccdデーモンを実行するのも忘れないでください：

root #

rc-update add distccd default

root #/etc/init.d/distccd start

中間生成物のキャッシュ

ccache とは

ccacheは高速なコンパイラキャッシュです。アプリケーションがコンパイルされると、毎回ccacheは中間生成物をキャッシュします。これによって、同じプログラムの同じバージョンが再コンパイルされるといつでも、コンパイル時間は大幅に減少します。最初にccacheが実行される時、コンパイル速度は通常より遅くなるでしょう。しかし、次からの再コンパイルは早くなるはずです。ccacheは同じアプリケーションの同じバージョンが何回も再コンパイルされる時にのみ便利なもので、それゆえこれはほとんどの場合、ソフトウェア開発者にのみ便利なものです。

ccacheに関するさらなる情報については、ホームページを訪れてください。

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

root #FEATURES="-ccache" emerge --oneshot <category/package>

ccache のインストール

ccacheをインストールするには、次のコマンドを実行してください：

root #emerge --ask dev-util/ccache

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

/etc/portage/make.confを開き、ccacheをFEATURES変数に追加してください。もしFEATURESが存在しなければ新たに定義してください。次に、CCACHE_SIZEと呼ばれる新しい変数を追加し、2Gと設定します：

ファイル /etc/portage/make.confPortageのccacheサポートを有効にする

FEATURES="ccache"
CCACHE_SIZE="2G"

ccacheが機能しているか確認するには、ccacheの統計を出すようにしてください。Portageは異なったccacheのホームディレクトリを使用しているため、一時的にCCACHE_DIR変数に値を格納する必要があります：

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

/var/tmp/ccache/はPortageのデフォルトのccacheホームディレクトリですが、/etc/portage/make.conf内でCCACHE_DIR変数を変更することで場所を変えることができます。

ccacheが単独で機能している時、ccacheは${HOME}/.ccache/を既定の場所として使用するでしょう。これが、（Portageの）ccacheの統計を取得する時に、CCACHE_DIR変数が設定されている必要がある理由です。

ccache を Portage の外で使う

ccacheをPortage以外のコンパイルの時に使用するには、/usr/lib/ccache/bin/をPATH変数のはじめ（/usr/binの前）に追加してください。これはユーザのホームディレクトリにある~/.bash_profileを編集することでできます。~/.bash_profileを使用することは、PATH変数を定義する方法の1つです。

ファイル ~/.bash_profileccacheの場所を他のPATHの前に設定する

PATH="/usr/lib/ccache/bin:${PATH}"

バイナリパッケージのサポート

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

Portage はビルド済みパッケージのインストールに対応しています。

ビルド済みパッケージを作成するには、もしパッケージが既にシステムにインストールされているならばquickpkgコマンドを使用してください。あるいは--buildpkgまたは--buildpkgonlyオプションを使用してemergeしてください。

Portageに、インストールするすべての単一のパッケージの、ビルド済みバージョンを作成させるには、FEATURES</var.変数にbuildpkgを追加してください。

ビルド済みパッケージの作成に対する拡張サポートは、catalyst を使用して受けることが出来ます。catalyst についての詳細は Catalyst FAQ を読んでください。

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

Gentooは対応していませんが、ビルド済みパッケージが保存される中央リポジトリを作成することが可能です。このリポジトリを使用するために、PORTAGE_BINHOSTにそのリポジトリを指定することでPortageに認識させることが必要です。例えば、ビルド済みパッケージがftp://buildhost/gentooにある場合：

ファイル /etc/portage/make.confPORTAGE_BINHOSTに場所を追加

PORTAGE_BINHOST="ftp://buildhost/gentoo"

ビルド済みパッケージをインストールする時は、emergeコマンドに--getbinpkgオプションを、--usepkgオプションと一緒に追加してください。前者はemergeに、予め定義されたサーバからビルド済みパッケージをダウンロードすることを伝え、後者はemergeに、ソースコードを取ってきてコンパイルする前に、先にビルド済みパッケージのインストールを試みるようemergeに要請します。

例えば、gnumericをビルド済みパッケージを用いてインストールする場合：

root #emerge --usepkg --getbinpkg gnumeric

emergeのビルド済みパッケージのオプションに関するさらなる情報については、emergeのmanページで見ることができます：

user $man emerge

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

もしビルド済みパッケージを他人に配布する場合、それが許可されている事を確認してください。上流のパッケージ配布条件を確認してください。例えば、GNU GPLライセンスの下でリリースされているパッケージは、バイナリと一緒にソースコードも利用可能にしなければなりません。

もしビルド済みバイナリが配布不可能な場合、ebuildがRESTRICT変数内でbindist制限を定義しているかもしれません。この制限は、時々1つまたは複数のUSEフラグの条件付きとなっています。

既定では、Portageはこの制限によっていかなるパッケージもマスクすることはありません。これは/etc/portage/make.conf内のACCEPT_RESTRICT変数を設定することで、システム全体で変更することが出来ます。例えば、bindist制限のあるパッケージをマスクする場合、以下の行をmake.confに追加してください：

ファイル /etc/portage/make.confバイナリで配布可能なパッケージのみを受諾する

ACCEPT_RESTRICT="* -bindist"

emergeコマンドに--accept-restrictオプションを渡すことで、ACCEPT_RESTRICT変数を上書きすることも可能です。例えば、--accept-restrict=-bindistでは、一時的にbindist制限のあるパッケージをマスクします。

また、パッケージを配布する時に ACCEPT_LICENSE 変数を設定することも検討してください。これに関しては、ライセンスの節を確認してください。

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

ファイルのフェッチ

distfiles を検証する

整合性を再認証し、場合によっては現在インストールされているすべてのパッケージに関する、過去に削除されたあるいは破損したdistfilesを再ダウンロードするには、次のコマンドを実行してください：

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

← USE フラグ Home Initスクリプトシステム →

重要
このページの内容は適切なプロファイルを選ぶで systemd プロファイルを選択したユーザには適用されません。

ランレベル

システムの起動

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

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

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

全てのスクリプトを実行したら、initは最後に端末 (ほとんどの場合 Alt+F1 や Alt+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 の以下の行で定義されています:

ファイル /etc/inittab初期化コマンド

si::sysinit:/sbin/openrc sysinit

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

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

ファイル /etc/inittabブートコマンドの実行

rc::bootwait:/sbin/openrc boot

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

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

ファイル /etc/inittabデフォルトランレベルの選択

id:3:initdefault:

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

ファイル /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 はどの仮想コンソールを有効化すべきか、また各コンソールでどのコマンドを実行しなければならないかを決定します:

ファイル /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つのユーザー定義ランレベルです。内部ランレベルはそれぞれ sysinit、shutdown そして reboot と呼ばれており、まさに名前が示す通りに動作します: システムの初期化、システムのパワーオフ、そしてシステムの再起動を行うのです。

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

init スクリプトの使い方

openrc プロセスが開始するスクリプトは init スクリプトと呼ばれます。/etc/init.d/ 内の各スクリプトは start、stop、restart、zap、status、ineed、iuse、iwant、needsme、usesme あるいは wantsme という引数で実行することができます。

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

root #rc-service postfix start

メモ
指定されたサービスを必要(need)とするサービスのみが停止または再起動されます。その他の依存サービス(指定されたサービスを使用(use)するが必要(need)としないもの)は影響されません。

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

root #rc-service --nodeps postfix stop

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

root #rc-service postfix status

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

root #rc-service postfix zap

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

root #rc-service postfix ineed

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

root #rc-service postfix needsme

ランレベルの更新

rc-update

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

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

サービスの追加と削除

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

init スクリプトを追加または削除するには、rc-update に add または 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 サーバーに起動時に渡すオプションを含めることができます:

ファイル /etc/conf.d/apache2apache2 init スクリプト用のオプションの例

APACHE2_OPTS="-D PHP5"

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

init スクリプトを書く

有用な資料として OpenRC の service script guide もあります。

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

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

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

レイアウト

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

コード (伝統的な) init スクリプトのレイアウト例

#!/sbin/openrc-run
  
depend() {
#  (依存関係情報)
}
  
start() {
#  (サービスを開始するのに必要なコマンド群)
}
  
stop() {
#  (サービスを止めるのに必要なコマンド群)
}

コード （更新された）initスクリプトのレイアウト例

#!/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() {
#  (依存関係の情報)
}
 
start_pre() {
#  (サービスを開始する準備に必要なコマンド群)
    # ディレクトリが確実に正しい設定であることを確かめてください
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (サービス後の片付けに必要なコマンド群)
    # 残ったものを片付ける
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

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

依存関係

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

use の設定は、このスクリプトが選択されたスクリプトによって提供される機能を使う(use)ものの、それに直接は依存していないことを init システムに対し通知します。use logger や use 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 の依存情報を見てみましょう:

ファイル /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 サービスを見てみましょう。

ファイル /etc/init.d/portmapportmap サービスの依存情報

depend() {
  need net
  before inetd
  before xinetd
}

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

コード * グロブの使用

depend() {
  before *
}

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

コード need localmount、after bootmisc とした依存設定

depend() {
  need localmount
  after bootmisc
}

標準関数

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

コード 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 変数の内容を調べる必要があります。

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

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

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

コード 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 に変わります:

コード 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)の場合に利用可能です

コード restartdelay メソッドの定義例

extra_started_commands="restartdelay"
  
restartdelay() {
  stop
  sleep 3    # Wait 3 seconds before starting again
  start
}

重要
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.conf の rc_hotplug 変数を使います:

ファイル /etc/rc.confWLAN インターフェースのホットプラグを有功にする

rc_hotplug="net.wlan !net.*"

メモ
デバイスによって開始されるサービスについての詳細は /etc/rc.conf 内のコメントを見てください。

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

bootlevel を使う

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

← Portageの機能 Home 環境変数 →

環境変数

はじめに

環境変数とは、1つまたは複数のアプリケーションで使われる情報を格納する名前付きオブジェクトです。環境変数を使用することで1つまたは複数のアプリケーションの設定を簡単に変更できます。

重要な例

以下の表は Linux システムで使われる数多くの変数を列挙し、使用方法の説明を加えたものです。値の例は表の後にあります。

変数	説明
`PATH`	この変数は、システムが実行可能ファイルを探索するディレクトリーのコロン区切りのリストを含みます。ある実行可能ファイルの名前 (ls、rc-update、あるいは emerge など) が入力されても、この実行可能ファイルがリストに含まれるディレクトリー内にない場合には (/bin/ls のようにフルパスがコマンドとして入力されない限り) システムはそれを実行しません。
`ROOTPATH`	この変数は `PATH` と同様の機能を持っていますが、こちらは root ユーザーがコマンドを入力した時にチェックされるディレクトリーのみが列挙されています。
`LDPATH`	この変数は動的リンカがライブラリを探すときに検索するディレクトリーのコロン区切りのリストを含みます。
`MANPATH`	この変数は man(1) コマンドが man ページを検索するディレクトリーのコロン区切りのリストを含みます。
`INFODIR`	この変数は info(1) コマンドが info ページを検索するディレクトリーのコロン区切りのリストを含みます。
`PAGER`	この変数は (less や more(1) のような) ファイル内容を表示するのに使用されるプログラムへのパスを含みます。
`EDITOR`	この変数は (nano や vi のような) ファイルを編集するのに使用されるプログラムへのパスを含みます。
`KDEDIRS`	この変数は KDE 特有の素材を含むディレクトリーのコロン区切りのリストを含みます。
`CONFIG_PROTECT`	この変数はパッケージアップデートの間 Portage によってプロテクトされるディレクトリーのスペース区切りのリストを含みます。
`CONFIG_PROTECT_MASK`	この変数はパッケージアップデートの間 Portage によってプロテクトされるべきでないディレクトリーのスペース区切りのリストを含みます。

以下はこれらの変数すべての定義例です:

コード ここで触れた変数の設定例

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"

変数を全体に設定する

env.d ディレクトリー

これらの変数の定義を集約するため、Gentoo では /etc/env.d/ ディレクトリーが導入されています。このディレクトリーの中には 50baselayout や gcc/config-x86_64-pc-linux-gnu といった数多くのファイルがあり、そこにはファイル名が表すアプリケーションで必要とされる変数が含まれています。

たとえば gcc がインストールされると、ebuild によって以下の変数の定義を含む gcc/config-x86_64-pc-linux-gnu という名前のファイルが作成されます:

ファイル /etc/env.d/gcc/config-x86_64-pc-linux-gnuGCC 13 のためにデフォルトの gcc が有効化された環境変数

GCC_PATH="/usr/x86_64-pc-linux-gnu/gcc-bin/13"
LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/13:/usr/lib/gcc/x86_64-pc-linux-gnu/13/32"
MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man"
INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info"
STDCXX_INCDIR="g++-v13"
CTARGET="x86_64-pc-linux-gnu"
GCC_SPECS=""
MULTIOSDIRS="../lib64:../lib"

他のディストリビューションでは、システム管理者はこうした環境変数の定義を /etc/profile やその他の場所で変更または追加するよう指示されるでしょう。一方 Gentoo ではシステム管理者 (と Portage) は環境変数を含む可能性がある多数のファイルに注意を払うことなく環境変数を維持管理できます。

たとえば gcc が更新された場合、/etc/env.d/gcc の下にある関連するファイルも管理者の関与を一切求めずに更新することができます。

それでもまだ、システム管理者にはある環境変数をシステム全体でセットするよう求められる場合があるでしょう。一例として http_proxy 変数を取り上げてみましょう。/etc/profile ディレクトリの下のファイルを編集するのではなく、/etc/env.d/99local という名前のファイルを作成してそこに定義を入れてください:

ファイル /etc/env.d/99localグローバル環境変数をセットする

http_proxy="proxy.server.com:8080"

カスタマイズされるすべての環境変数について同じファイルを使うことで、システム管理者は自身が定義した変数を素早く見ることができます。

env-update

/etc/env.d/ ディレクトリ内のいくつかのファイルは PATH 変数に定義を追加しています。これは間違いではありません: env-update コマンドは実行されると、いくつかの定義を結合してそれぞれの環境変数をアトミックに更新します。これによって、パッケージ (やシステム管理者) が自身の環境変数の設定をすでに存在する値と干渉しないように追加するのが簡単になります。

env-update スクリプトは値を /etc/env.d/ にあるファイルのアルファベット順で結合します。ファイル名は2桁の10進数で始めないといけません。

コード env-update で使用される更新順序

09sandbox    50baselayout     51dconf
     +------------+----------------+-----------+
CONFIG_PROTECT_MASK="/etc/sandbox.d /etc/gentoo-release /etc/dconf ..."

変数の結合は常に起こるわけではなく、以下の変数でのみ行われます: 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、そして PYTHONPATH。それ以外のすべての変数では (/etc/env.d/ のファイルのアルファベット順で) 最後に定義された値が使われます。

変数名を COLON_SEPARATED または SPACE_SEPARATED 変数のどちらかに(これまた /etc/env.d/ 内のファイルで)追加することで、この結合される変数のリストにさらなる変数を追加することができます。

env-update を実行すると、スクリプトはすべての環境変数を作成してそれを /etc/profile.env (これは /etc/profile によって使用されます) に格納します。また LDPATH 変数から情報を展開して /etc/ld.so.conf を作成します。その後スクリプトは ldconfig を実行して、動的リンカが使用する /etc/ld.so.cache を再作成します。

env-update の効果を実行後すぐに有効にするには、以下のコマンドを実行して環境を更新してください。Gentoo を自分自身でインストールしたユーザーは、おそらくインストールの説明でこれを見たことを思い出すかもしれませんね:

root #env-update && source /etc/profile

メモ
上のコマンドは現在の端末、新しいコンソールおよびそれらの子孫での変数のみを更新します。したがって、ユーザーが X11 で作業している場合、新しく開いた端末すべてで source /etc/profile と打ち込むかあるいは X を再起動して、すべての新しい端末が新しい変数を読み込むようにする必要があります。ログインマネージャーを使用している場合は root になって /etc/init.d/xdm サービスを再起動する必要があります。

重要
シェル変数を他の変数の定義に使用することはできません。つまり、FOO="$BAR" ($BAR はもう一つの変数) といったことは禁止されているということです。

変数を局所的に設定する

ユーザーごと

環境変数を全体に設定する必要はないこともあります。たとえば、あるユーザーは /home/my_user/bin と作業ディレクトリ (ユーザーが今いるディレクトリ) を PATH 変数に追加したいが、これらのディレクトリをシステム上の他のすべてのユーザーの PATH には含めたくない場合などです。環境変数を局所的に定義するには、~/.bashrc (すべての対話的シェルセッションに対して) または ~/.bash_profile (ログインシェルセッションに対して) を使用します:

ファイル ~/.bashrcPATH をローカルでの使用のために拡張する

# 後ろにディレクトリーが続かないコロンは現在の作業ディレクトリーとして扱われます
PATH="${PATH}:/home/my_user/bin:"

ログアウト/ログインすると PATH 変数が更新されます。

セッションごと

時には、さらに厳格な定義が求められる場合もあります。たとえば、一時ディレクトリーにあるバイナリーを、それらへのフルパスを使用する必要なく、また一時的に ~/.bashrc を編集するも必要なく、使用できるようにしたい場合です。

この場合、現在のプロファイルでの PATH 変数を単に export コマンドを使って定義します。ユーザーがログアウトするまでの間は PATH 変数にその一時的な設定が使われます。

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

← Initスクリプトシステム Home ファイルとディレクトリ →

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

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

Portage へようこそ

Gentoo リポジトリ

Ebuild

Gentoo リポジトリの更新

ソフトウェアを保守する

ソフトウェアの検索

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

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

ソフトウェアの削除

システムの更新

メタパッケージ

ライセンス

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

用語について

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

マスクされたパッケージ

USE フラグの変更が必要

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

あいまいな ebuild 名

循環依存

フェッチ失敗

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

ダイジェスト検証失敗

USE フラグとは何ですか

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

USE フラグの定義

USE フラグを使う

永続的な USE フラグの宣言

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

USE フラグの一時的な宣言

優先順位

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

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

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

REQUIRED_USE 条件を満足させる

Portage の機能

分散コンパイル

distcc を使う

distcc のインストール

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

中間生成物のキャッシュ

ccache とは

ccache のインストール

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

ccache を Portage の外で使う

バイナリパッケージのサポート

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

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

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

ファイルのフェッチ

distfiles を検証する

ランレベル

システムの起動

Initscripts

init の仕組み

有効なランレベル

init スクリプトの使い方

ランレベルの更新

rc-update

サービスの追加と削除

サービスの設定

追加の設定が必要な理由

conf.d ディレクトリ

init スクリプトを書く

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

レイアウト

依存関係

順序の制御

標準関数

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

サービス設定変数

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

これが役に立つ人

softlevel を使う

bootlevel を使う

環境変数

はじめに

重要な例

変数を全体に設定する

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