Gentoo Linux mips ハンドブック:Gentoo での作業
Portage へようこそ
portageはソフトウェア管理における、Gentooの最も特筆すべき技術革新のひとつです。その高い柔軟性と膨大な量の機能により、Linuxで利用可能な最高のソフトウェア管理ツールであると見なされることもしばしばです。
portageはすべてPythonとBashで書かれています。どちらもスクリプト言語なので、ユーザはそのすべてを見ることができます。
ほとんどのユーザはemergeというツールを挟んでPortageを利用することになるでしょう。この章はemergeのmanページにある情報をすべて記述することを目的とはしていません。emergeのオプションの完全な概要については、manページを参照してください：
user $man emergeGentoo リポジトリ
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リリースエンジニアリングGPG鍵によって署名されたスナップショットだけを取得したい時にも emerge-webrsync が役に立つことでしょう。これに関する詳細は "Portageの機能" 記事の検証済みのGentooリポジトリスナップショットで読むことができます。
ソフトウェアを保守する
ソフトウェアの検索
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パッケージのインストールの過程で、Portageは(必要なら)ソースコードをインターネット上からダウンロードし、デフォルトでは /var/cache/distfiles/ に保存します。インストールせずにダウンロードだけさせたい時は、--fetchonly オプションを emerge コマンドにつけます。
root #emerge --fetchonly gnumericインストールしたパッケージのドキュメントを探す
多くのパッケージにはドキュメントが付属しています。そしてドキュメントをインストールするかどうかを選択する doc USEフラグが用意されていることがあります。パッケージで doc USEフラグが使われるかどうかは、emerge -vp category/package で調べることができます:
root #emerge -vp media-libs/alsa-libThese 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.3total 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 @worldPortageはインストール済みのアプリケーションに新しいバージョンがあるかどうかを調べます。しかし、これは明示的にインストールされたアプリケーション (/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は、孤独な依存関係を削除する機能も備えています。しかし、ソフトウェアの可用性は動的依存のため、まずシステム全体を完全にアップデートすることが重要です。これにはUSEフラグの変更が適用された新しい変更も含みます。これの後、emerge --depcleanを実行し、孤独な依存関係を削除することが出来ます。これが完了したら、今削除されたソフトウェアと動的にリンクしていたが、もはやそのソフトウェアを必要としないアプリケーションの再ビルドが必要かもしれません。尤も、最近このサポートはPortageに追加されましたが。
以上のことのすべては3コマンドで行われます:
root #emerge --update --deep --newuse @world
root #emerge --depclean
root #revdep-rebuildrevdep-rebuild は app-portage/gentoolkit パッケージによって提供されているので、忘れずに emerge しておいてください:
root #emerge --ask app-portage/gentoolkitライセンス
Portage バージョン 2.1.7 以降、ライセンスを基準にソフトウェアのインストールを許可または拒否することができます。ツリー内のすべてのパッケージは LICENSE エントリを含みます。emerge --search package/category を実行するとパッケージのライセンスが表示されます。
ebuildのLICENSE変数はGentooの開発者やユーザにとってのガイドラインでしかありません。これは法的声明ではなく、これが現実を反映する保証はありません。したがって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 パッケージのインストールは禁止されます。
ライセンスは /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 を使うと、ひとつのパッケージの異なる複数のバージョンをシステム上に共存させることができます。他のディストリビューションはパッケージ名をバージョンにちなんで命名する（例えば 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 リポジトリにコミットした開発者が異なるアーキテクチャ上で動作するか確認できない、などの理由がありえます。
それぞれのGentooインストールは、システムが通常通り機能するために必要な、パッケージのリストを含む情報を格納している特定のプロファイルに従っています。
ブロックされたパッケージ
[blocks B ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
!!! 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 のバグトラッキングシステムにバグを報告してください。
マスクされたパッケージ
!!! all ebuilds that could satisfy "bootsplash" have been masked.
!!! 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フラグの変更が必要
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 がセットされていないと、次のようなエラーメッセージも表示されるかもしれません:
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 内で特定のパッケージに対してセットしてください。
依存パッケージが見つからない
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名
[ 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 は何から選べばいいか、マッチしたものを教えてくれるでしょう。
循環依存
!!! 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 をチェックしてこの問題が既知のものであるか確認し、そうでなければ報告することも有益でしょう。
フェッチ失敗
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing... (...) !!! Some fetch errors were encountered. Please see above for details.
Portage が与えられたアプリケーションのソースをダウンロードできなかったため、他のアプリケーションのインストール（するものがあれば）を続行しようとしています。この失敗は、正しく同期されていないミラーのために、あるいは ebuild が正しくないダウンロード先を指しているために起こることがあります。ソースを置いているサーバが何らかの理由でダウンしていることも考えられます。
1 時間ほど時間をおいて再試行し、問題が継続しているか確認してください。
システムプロファイルによる保護
!!! 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 (IRC) で聞いてください。まだであれば、遠慮なく壊れた ebuild のためにバグを提出してください。
バグが修正されたら、Gentoo ebuild リポジトリを再同期して修正されたダイジェストを引っ張ってきてください。
Gentoo ebuild リポジトリを一日一回以上同期しないように気をつけてください。公式の Gentoo ネチケットポリシーに書かれている通り（また emerge --sync を実行したときにも表示される通り）、あまりにも頻繁に同期するユーザは当面の間、それ以上の同期を禁止されます。このポリシーにも繰り返し違反する悪用者は完全にアクセスを禁止されることがあります。再同期が Gentoo の rsync ミラーに過剰な負荷を与えないようにするために、どうしても必要な場合を除いて 24 時間周期で同期されるのを待つのが最善です。
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 フラグには２種類あります。グローバル USE フラグと、ローカル USE フラグです。
- グローバル USEフラグは、いくつかのパッケージに、システムワイドに使われるものです。ほとんどの人にとって、USEフラグといえばこれを指します。利用できるグローバルUSEフラグの一覧は、メインサイト あるいはローカルの /var/db/repos/gentoo/profiles/use.desc ファイルにあります。
- ローカル USEフラグは、単一のパッケージに、パッケージ固有の選択のために使われるものです。利用できるローカルUSEフラグの一覧は、メインサイト あるいはローカルの /var/db/repos/gentoo/profiles/use.local.desc ファイルにあります。
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 ^USEUSE="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 -qt4 -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フラグでは不要になった条件付きの依存パッケージを削除しましょう。
emerge --depclean の実行は危険な操作であり、注意して行われるべきです。提供される"不要になった"パッケージの一覧をダブルチェックし、必要なパッケージが削除されないことを確認してください。次の例では、
-p スイッチを追加することで、depcleanがパッケージの一覧表示のみを行い、削除を行わないようにしています:
root #emerge -p --depcleandepcleanが完了したらemerge は、削除されたかもしれないパッケージが提供していた共有オブジェクトに対して動的リンクされていたアプリケーションをリビルドするよう促すかもしれません。Portageはアプリケーションを破壊するのを防ぐため、このアクションが取られるまで必要なライブラリを保存します。Portageはリビルドが必要なものをpreserved-rebuildセットに登録します。必要なパッケージをリビルドするためには、次のコマンドを実行してください：
root #emerge @preserved-rebuildこれらの全てを完遂したとき、システムは新たなUSEフラグ設定を用いることになります。
パッケージ固有の USE フラグ
利用可能な USE フラグを表示する
それでは、seamonkeyの例を見てみましょう: これはどんなUSEフラグに影響されるのでしょう？ 確かめるために、emergeを --pretend と --verbose オプションつきで使います:
root #emerge --pretend --verbose www-client/seamonkeyThese 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フラグを見てみましょう。例えば、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 がセットされているなら、 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 の機能
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=gnomeまたはUSE=gtkが設定されていると自動的にインストールされます。
root #emerge --ask sys-devel/distccPortage の 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" を書く) 再コンパイルしてみてください。ccache のインストール
ccacheをインストールするには、次のコマンドを実行してください：
root #emerge --ask dev-util/ccachePortage の 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はビルド済みパッケージのインストールに対応しています。Gentoo自体はビルド済みパッケージを提供していませんが、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 gnumericemergeのビルド済みパッケージのオプションに関するさらなる情報については、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変数を設定することも検討してください。これに関しては、Licensesセクションを確認してください。
パッケージのライセンスとそれぞれの国の法律に従うことは、あくまで各 "ユーザー" の責任です。ebuildに書かれたメタデータ変数 (RESTRICT や LICENSE) はバイナリ配布の制限などの案内を提供しますが、Portageの出力やGentoo開発者による回答は法的な意味を持つものではなく、これをあてにするべきではありません。お住いの地域の法律に反しないよう、十分に注意してください。
ファイルのフェッチ
Userfetch
Portageがは通常rootユーザとして実行されます。FEATURES="userfetch" を設定しておくことで、パッケージソースを取得するときにroot権限を放棄し、portage:portageのユーザ/グループで実行するようになります。これはちょっとしたセキュリティの向上につながります。
もしuserfetchがFEATURES内で設定されているならば、確実に/var/db/repos/gentoo内にあるすべてのファイルの所有者を、chownをroot特権で実行することで変更するようにしてください。
root #chown --recursive --verbose portage:portage /var/db/repos/gentoo検証済みのGentooリポジトリスナップショット
管理者は、ローカルのGentoo ebuildリポジトリを、Gentoo基盤がリリースする暗号検証済みのスナップショットにアップデートすることを選択できます。これによって悪質なrsyncミラーが、システムがダウンロードするリポジトリに望まれていないコードやパッケージを追加するのを防ぐことが出来ます。
以下は、repos.confを使用した、emerge-webrsyncのsync手段を利用し設定するアップデートされた方法です。
GentooリリースメディアのOpenPGP鍵は、現在バイナリキーリングとして利用可能です。これらはapp-crypt/gentoo-keysパッケージを経由してインストールすることが出来ます：
root #emerge --ask app-crypt/gentoo-keys
/etc/portage/make.confPortage の GPG サポートを有効にするFEATURES="webrsync-gpg" PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release"
/etc/portage/repos.conf/gentoo.confsync-uri変数の値を消去する[DEFAULT] main-repo = gentoo [gentoo] # 変数の値を消去するか、auto-sync = noと設定することで同期を無効にします # この設定ファイルの変数に値を与えるのに、クオート（''や""）を使用しないでください！ # portage-2.2.18については'websync'を使用してください。 # portage-2.2.19やそれ以上のバージョンについては、'webrsync'を使用してください（websyncはwebrsyncに改名されました） sync-type = webrsync sync-uri = auto-sync = yes
app-crypt/gnupg をインストールすることを忘れないでください:
root #emerge --ask app-crypt/gnupggpgを使用して、キーリング中の鍵が正しい鍵であることを確かめてください：
root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --with-fingerprint --list-keys --keyid-format 0xlong鍵の指紋を、公式Gentooリリースエンジニアリングプロジェクトのページで一覧になっている指紋に対し確かめてください。
万一app-crypt/gentoo-keysからインストールした鍵のどれかが期限切れとなっているなら、app-crypt/gkeysのgkeysを実行し、鍵サーバからこれらの鍵をリフレッシュしてください：
root #emerge --ask app-crypt/gkeysroot #gkeys refresh-key -C gentoo信用したい鍵それぞれに対し、以下のコマンドを実行してください（鍵idの'0x...'を信用したい鍵に置き換えてください）。
root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --edit-key 0xDB6B8C1F96D8BF6D trustGPGコマンドラインメニューが現れるはずですので、以下のコマンドを打ち、鍵を十分に信用し、プログラムを終了してください：
gpg>4
gpg>quit
これでシステムはOpenPGP/gpgによって認証されたスナップショットのみをsyncに使用するよう設定されました。
syncを実行するのにいくつかのコマンドが利用可能です。
実際に必要になるのは次のコマンドのうち一つだけです。詳細は Portage の sync について書かれたWiki記事 をご覧ください。
root #emerge --syncroot #emaint sync -aroot #emaint sync --repo gentooroot #emerge-webrsyncdistfilesを認証する
整合性を再認証し、場合によっては現在インストールされているすべてのパッケージに関する、過去に削除されたあるいは破損したdistfilesを再ダウンロードするには、次のコマンドを実行してください：
root #emerge --ask --fetchonly --emptytree @world
ランレベル
システムの起動
システムが起動すると、たくさんのテキストが流れます。注意して見ると、(通常) それが毎回同じ内容であることに気づくでしょう。これら全てのアクションの実行はブートシーケンスと呼ばれ、(ほぼ) 静的に定義されます。
まずブートローダーが、ブートローダーの設定で定義されたカーネルイメージを読み込みます。そしてブートローダーは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 #/etc/init.d/postfix start指定されたサービスを必要(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サービスがどのような依存関係を持っているか問い合わせるには、iwant、iuse あるいは ineed 引数を使用します。ineed を使うとそのサービスが正しく機能するために本当に必要なサービスが表示されます。一方 iwant や iuse は、そのサービスから使用することができるけれども、正しく機能する上で必要というわけではないサービスを表示します。
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 スクリプトは動作を定義する第二の引数を必要とします: add、del または show です。
init スクリプトを追加または削除するには、rc-update に add または del 引数、その後に init スクリプトとランレベルを渡します。一例:
root #rc-update del postfix defaultrc-update -v show コマンドは利用可能なすべての init スクリプトと、それらが実行されるランレベルの一覧を出力します:
root #rc-update -v showrc-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スクリプトを書く
これは必要な作業なんですか？
いいえ、Gentoo は提供しているすべてのサービスについてそのまま使える init スクリプトを提供しているので、通常は init スクリプトを書く必要はありません。しかしながら、一部のユーザーは Portage を使わずにサービスをインストールしているかもしれません。このような場合にはたいてい init スクリプトを作成しなければなりません。
サービスによって提供されている init スクリプトは、明示的に Gentoo 用に書かれているのでなければ使用してはいけません: Gentoo の init スクリプトは他のディストリビューションで使われている init スクリプトとは互換性がありません！ そのディストリビューションが OpenRC を使っているのでない限りは、ということですが！
レイアウト
init スクリプトの基本構造は以下の通りです。
#!/sbin/openrc-run depend() { # (依存関係情報) } start() { # (サービスを開始するのに必要なコマンド群) } stop() { # (サービスを止めるのに必要なコマンド群) }
#!/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/ に pidfile といったものを配置する場合は bootmisc の後(after)に起動すべきです。
depend() { need localmount after bootmisc }
標準関数
depend() 関数に続いて、start() 関数も定義する必要があります。これにはサービスを初期化するために必要なすべてのコマンドが含まれています。ユーザーに何が起きているか通知するため ebegin および eend 関数を使用することをお勧めします:
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() { 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 に変わります:
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-daemonGentoo の init スクリプトの文法は POSIX シェルをもとにしているので、init スクリプトの中で sh 互換の構文を使うことができます。Gentoo がもし init システムに変更を加えてもスクリプトが機能し続けるようにするために、それ以外の構文、たとえば bash 特有のものなどは init スクリプトに含めないでください。
カスタムオプションの追加
init スクリプトがこれまでに見たもの以外のオプションをサポートする必要がある場合、そのオプションを以下の変数のうちの一つに追加し、オプションと同名の関数を作成してください。たとえば restartdelay というオプションをサポートするには:
- extra_commands - コマンドはすべての状態のサービスにおいて利用可能です
- extra_started_commands - コマンドはサービスが開始済み(started)の時に利用可能です。
- extra_stopped_commands - コマンドはサービスが停止中(stopped)の場合に利用可能です
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" ランレベルが定義されることです。
環境変数
はじめに
環境変数とは、1つまたは複数のアプリケーションで使われる情報を格納する名前付きオブジェクトです。環境変数を使用することで1つまたは複数のアプリケーションの設定を簡単に変更できます。
重要な例
以下の表は Linux システムで使われる数多くの変数を列挙し、使用方法の説明を加えたものです。値の例は表の後にあります。
| 変数 | 説明 |
|---|---|
| PATH | この変数は、システムが実行可能ファイルを探索するディレクトリーのコロン区切りのリストを含みます。ある実行可能ファイルの名前 (ls、rc-update、あるいは emerge など) が入力されても、この実行可能ファイルがリストに含まれるディレクトリー内にない場合には (/bin/ls のようにフルパスがコマンドとして入力されない限り) システムはそれを実行しません。 |
| ROOTPATH | この変数は PATH と同様の機能を持っていますが、こちらは root ユーザーがコマンドを入力した時にチェックされるディレクトリーのみが列挙されています。 |
| LDPATH | この変数は動的リンカがライブラリを探すときに検索するディレクトリーのコロン区切りのリストを含みます。 |
| MANPATH | この変数は man コマンドが man ページを検索するディレクトリーのコロン区切りのリストを含みます。 |
| INFODIR | この変数は info コマンドが info ページを検索するディレクトリーのコロン区切りのリストを含みます。 |
| PAGER | この変数は (less や more のような) ファイル内容を表示するのに使用されるプログラムへのパスを含みます。 |
| 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/ ディレクトリーが導入されています。このディレクトリーの中には 00basic や 05gcc といった数多くのファイルがあり、そこにはファイル名が表すアプリケーションで必要とされる変数が含まれています。
たとえば gcc がインストールされると、ebuild によって以下の変数の定義を含む 05gcc という名前のファイルが作成されます:
/etc/env.d/05gccデフォルトの gcc が有効化された環境変数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"
他のディストリビューションでは、ユーザーはこうした環境変数の定義を /etc/profile やその他の場所で変更または追加するよう指示されるでしょう。一方 Gentoo ではユーザー (と Portage) は環境変数を含む可能性がある多数のファイルに注意を払うことなく環境変数を維持管理できます。
たとえば gcc が更新された場合、/etc/env.d/05gcc ファイルもユーザーの関与を一切求めずに更新することができます。
これは Portage のみならずユーザーにとっても利益があります。ユーザーは時にある環境変数をシステム全体でセットするよう求められることがあるでしょう。一例として 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進数で始めないといけません。
00basic 99kde-env 99local
+-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"変数の結合は常に起こるわけではなく、以下の変数でのみ行われます: 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"
Warning: Display title "Gentoo Linux mips ハンドブック:Gentoo での作業" overrides earlier display title "ハンドブック:MIPS/フル/ワーキング".