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

This page is a translated version of the page Handbook:SPARC/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 Initscript system →

重要
The contents of this page do not apply to users that chose a systemd profile in Choosing the right profile.

Runlevels

Booting the system

When the system is booted, lots of text floats by. When paying close attention, one will notice this text is (usually) the same every time the system is rebooted. The sequence of all these actions is called the boot sequence and is (more or less) statically defined.

First, the boot loader will load the kernel image that is defined in the boot loader configuration. Then, the boot loader instructs the CPU to execute the kernel. When the kernel is loaded and run, it initializes all kernel-specific structures and tasks and starts the init process.

The init process makes sure that all filesystems (defined in /etc/fstab) are mounted and ready to be used. Then it executes several scripts located in /etc/init.d/, which will start the services needed in order to have a successfully booted system.

Finally, once all scripts have been executed, init activates the virtual consoles accessible via Ctrl+Alt+ F1, Ctrl+Alt + F2, etc.), attaching to each one a special process called agetty. This process ensures users are able to log on via login.

Initscripts

The scripts in /etc/init.d/ aren't executed randomly. init doesn't run all scripts in /etc/init.d/, only the scripts it is told to execute, via /etc/runlevels/.

First, init runs all scripts from /etc/init.d/ that have symbolic links inside /etc/runlevels/boot/. Usually, it will start the scripts in alphabetical order, but some scripts have dependency information in them, telling the system that another script must be run before they can be started.

Once all scripts referenced in /etc/runlevels/boot/ have been executed, init will run the scripts linked in /etc/runlevels/default/. Again, it will use the alphabetical order to decide what script to run first, unless a script has dependency information in it, in which case the order is changed to provide a valid start-up sequence. This is why commands used during the installation of Gentoo Linux use the default runlevel (e.g. rc-update add sshd default).

How init works

Of course init doesn't decide all that by itself. It needs a configuration file that specifies what actions need to be taken. The /etc/inittab file is used by init to determine the actions it needs to take.

As described above, init's first action is to mount all file systems. This is defined in the following line from /etc/inittab:

ファイル /etc/inittabInitialization command

si::sysinit:/sbin/openrc sysinit

This line tells init that it must run /sbin/openrc sysinit to initialize the system. The /sbin/openrc script takes care of the initialization, so one might say that init doesn't do much - it delegates the task of initializing the system to another process.

Second, init executed all scripts that had symbolic links in /etc/runlevels/boot/. This is defined in the following line:

ファイル /etc/inittabBoot command invocation

rc::bootwait:/sbin/openrc boot

Again the OpenRC script performs the necessary tasks. Note that the option given to OpenRC (boot) is the same as the sub-directory of /etc/runlevels/ that is used.

Now init checks its configuration file to see what runlevel it should run. To decide this, it reads the following line from /etc/inittab:

ファイル /etc/inittabDefault runlevel selection

id:3:initdefault:

In this case (which the majority of Gentoo users will use), the runlevel id is 3. Using this information, init checks what it must run to start runlevel 3:

ファイル /etc/inittabRunlevel definitions

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

The line that defines level 3, again uses the openrc script to start the services (now with argument default). Also note again that the argument to openrc is the same as the subdirectory from /etc/runlevels/.

When OpenRC has finished, init decides what virtual consoles it should activate and what commands need to be run at each console:

ファイル /etc/inittabTerminal definitions

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

Available runlevels

In a previous section, we saw that init uses a numbering scheme to decide what runlevel it should activate. A runlevel is a state in which the system is running and contains a collection of scripts (runlevel scripts or initscripts) that must be executed when entering or leaving a runlevel.

In Gentoo, there are seven runlevels defined: three internal runlevels, and four user-defined runlevels. The internal runlevels are called sysinit, shutdown and reboot and do exactly what their names imply: initializing the system, powering off the system, and rebooting the system.

The user-defined runlevels are those with an accompanying /etc/runlevels/ subdirectory: boot, default, nonetwork and single. The boot runlevel starts all system-necessary services used by all the other runlevels. The remaining three runlevels differ in what services they start: default is used for day-to-day operations, nonetwork is used in case no network connectivity is required, and single is used when the system needs to be fixed.

Working with initscripts

The scripts that the openrc process starts are called init scripts. Each script in /etc/init.d/ can be executed with the arguments start, stop, restart, zap, status, ineed, iuse, iwant, needsme, usesme, or wantsme.

To start, stop, or restart a service (and all dependent services), the start, stop, and restart arguments should be used:

root #rc-service postfix start

メモ
Only the services that need the given service are stopped or restarted. The other dependent services (those that use the service but don't need it) are left untouched.

To stop a service, but not the services that depend on it, use the --nodeps option together with the stop argument:

root #rc-service --nodeps postfix stop

To get the status of a service (started, stopped, ...), use the status argument:

root #rc-service postfix status

If the status information shows that the service is running, but in reality it is not, then reset the status information to "stopped" with the zap argument:

root #rc-service postfix zap

To also ask what dependencies the service has, use iwant, iuse or ineed. With ineed it is possible to see the services that are really necessary for the correct functioning of the service. iwant or iuse, on the other hand, shows the services that can be used by the service, but are not necessary for the correct functioning of the service.

root #rc-service postfix ineed

Similarly, it is possible to ask what services require the service (needsme) or can use it (usesme or wantsme):

root #rc-service postfix needsme

Updating runlevels

rc-update

Gentoo's init system uses a dependency tree to decide what service needs to be started first. As this is a tedious task that we wouldn't want our users to have to do manually, we have created tools that ease the administration of the runlevels and init scripts.

With rc-update it is possible to add and remove init scripts to a runlevel. The rc-update tool will then automatically ask the depscan.sh script to rebuild the dependency tree.

Adding and removing services

In earlier instructions, init scripts have already been added to the default runlevel. What default means has been explained earlier in this document. Next to the runlevel, the rc-update script requires a second argument that defines the action: add, del, or show.

In addition to the runlevel, the rc-update script requires a second argument specifying the appropriate action: add, del, or show. For instance:

root #rc-update del postfix default

The rc-update -v show command will show all the available init scripts and the runlevels in which they will execute:

root #rc-update -v show

It is also possible to run rc-update show (without -v) to just view enabled init scripts and their runlevels.

Configuring services

Why additional configuration is needed

Init scripts can be quite complex. It is therefore not desirable to have users edit init scripts directly, as it would make them more error-prone. However, it's important to be able configure services: for instance, users might want to run the service with additional options.

A second reason to have this configuration outside the init script is to be able to update the init scripts without the fear that the user's configuration changes will be undone.

conf.d directory

Gentoo provides an easy way to configure such a service: every init script that can be configured has a file in /etc/conf.d/. For instance, the apache2 initscript (called /etc/init.d/apache2) has a configuration file called /etc/conf.d/apache2, which can contain the options to give to the Apache 2 server when it is started:

ファイル /etc/conf.d/apache2Example options for apache2 init script

APACHE2_OPTS="-D PHP5"

Such a configuration file contains only variables (just like /etc/portage/make.conf does), making it very easy to configure services. It also allows us to provide more information about the variables (as comments).

Writing initscripts

Another useful resource is OpenRC's service script guide.

Is it necessary?

No, writing an init script is usually not necessary as Gentoo provides ready-to-use init scripts for all provided services. However, some users might have installed a service without using Portage, in which case they will most likely have to create an init script.

Do not use the init script provided by the service if it isn't explicitly written for Gentoo: Gentoo's init scripts are not compatible with the init scripts used by other distributions, unless the other distribution is using OpenRC.

Layout

The basic layout of an init script is shown below.

コード Example initscript layout (traditional)

#!/sbin/openrc-run
  
depend() {
#  (Dependency information)
}
  
start() {
#  (Commands necessary to start the service)
}
  
stop() {
#  (Commands necessary to stop the service)
}

コード Example initscript layout (updated)

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="FooBar Daemon"
 
description="FooBar is a daemon that drinks"
extra_started_commands="drink"
description_drink="Opens mouth and reflexively swallows"
 
depend() {
#  (Dependency information)
}
 
start_pre() {
#  (Commands necessary to prepare to start the service)
    # Ensure that our dirs are correct
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commands necessary to clean up after the service)
    # Clean any spills
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

Every init script requires the start() function or command variable to be defined. All other sections are optional.

Dependencies

There are three dependency-related settings which can influence the start-up or sequencing of init scripts:: want, use and need. Next to these, there are also two order-influencing methods called before and after. These last two are not dependencies per se - they don't make the init script fail if the specified dependency isn't scheduled to start (or fails to start).

The use setting informs the init system that the script uses functionality offered by the selected script, but does not directly depend on it. Some examples are use logger and use dns: if the services are available, they will be used, but if the system does not have a logger or DNS server, the services will still work. If the services exist, then they are started before the script that uses them.
The want setting is similar to use with one exception. use only considers services which were added to a runlevel; want will try to start any available service even if not added to any runlevel. want will try to start any available service even if not added to an init level.
The need setting indicates a hard dependency: a script that needs another script will not start before the latter script is started successfully. Also, if the needed script is restarted, the script needing it will be restarted as well.
The before setting ensures the script is launched before a specified script, if the latter is part of the runlevel. So an init script xdm that defines before alsasound will start before the alsasound script, but only if alsasound is scheduled to start in the same runlevel. If alsasound is not scheduled to start in that runlevel, then the before has no effect, and xdm will be started when the init system deems it most appropriate.
Similarly, after informs the init system that the given script should be launched after a specified script if the latter is part of the same runlevel. If not, then the setting has no effect and the script will be launched by the init system when it deems it most appropriate.

It should be clear from the above that need is the only "true" dependency setting, as it affects whether the script will be started or not. All the others merely tell the init system the order in which scripts can be (or should be) started.

Virtual dependencies

Many of Gentoo's init scripts depend on things that are themselves not init scripts: virtual dependencies.

A virtual dependency is a dependency that a service provides, but that is not provided solely by that service. An init script can depend on a system logger, but there are many system loggers available (metalogd, syslog-ng, sysklogd, ...). As the script cannot need every single one of them (no sensible system has all these system loggers installed and running) we made sure that all these services provide a virtual dependency.

For instance, consider the dependency information in the postfix script:

ファイル /etc/init.d/postfixDependency information of the postfix service

depend() {
  need net
  use logger dns
  provide mta
}

As can be seen, the postfix service:

Requires the (virtual) net dependency (which is provided by, for instance, /etc/init.d/net.eth0).
Uses the (virtual) logger dependency (which is provided by, for instance, /etc/init.d/syslog-ng).
Uses the (virtual) dns dependency (which is provided by, for instance, /etc/init.d/named).
Provides the (virtual) mta dependency (which is common for all mail servers).

Controlling the order

As described in the previous section, it is possible to tell the init system what order it should use for starting (or stopping) scripts. This ordering is handled both through the dependency settings use and need, but also through the order settings before and after. As we have described these earlier already, let's take a look at the portmap service as an example of such init script.

ファイル /etc/init.d/portmapDependency information of the portmap service

depend() {
  need net
  before inetd
  before xinetd
}

It's possible to use the * glob to refer to all services in the same runlevel, although this isn't advisable.

コード Using the * glob

depend() {
  before *
}

If the service must write to local disks, it should need localmount. If it places anything in /var/run/, such as a PID file, then it should start after bootmisc:

コード Dependency setting with needing localmount and after bootmisc

depend() {
  need localmount
  after bootmisc
}

Standard functions

In addition to the depend() functionality, it's also necessary to define the start() function. This function contains all the commands necessary to initialize the service. It's advisable to use the ebegin and eend functions to inform the user about what's happening:

コード Example start() function

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 $?
}

Both --exec and --pidfile should be used in start() and stop() functions. If the service doesn't create a PID file, then use --make-pidfile if possible, though it is recommended to test this to be sure. Otherwise, don't use PID files. It is also possible to add --quiet to the start-stop-daemon options, but this is not recommended unless the service is extremely verbose. Using --quiet may hinder debugging if the service fails to start.

Note also that the above example check the contents of the RC_CMD variable. OpenRC doesn't support script-specific restart functionality; instead, the script needs to check the contents of the RC_CMD variable to see if a function (e.g. start() or stop()) is being called as part of a restart or not.

メモ
Make sure that --exec actually calls a service and not just a shell script that launches services and exits - that's what the init script is supposed to do.

For more examples of the start() function, please read the source code of the available init scripts in the /etc/init.d/ directory.

Another function that can (but does not have to) be defined is stop(). The init system is intelligent enough to fill in this function by itself if start-stop-daemon is used.

コード Example stop() function

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

If the service runs some other script (for example, Bash, Python, or Perl), and this script later changes names (for example, from foo.py to foo), then it is necessary to add --name as an option to start-stop-daemon. This must specify the name that the script will be changed to. In this example, a service starts foo.py, which changes names to foo:

コード Example definition for a service that starts the foo script

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 has an excellent man page available if more information is needed:

user $man start-stop-daemon

Gentoo's init script syntax is based on the POSIX shell ('sh'), so people are free to use sh-compatible constructs inside their init scripts. Keep other constructs, like Bash-specific ones, out of init scripts to ensure that the scripts remain functional regardless of any changes Gentoo might make to its init system.

Adding custom options

If the initscript needs to support an option other than the ones we've already encountered, add the option to one of the following variables, and create a function with the same name as the option. For instance, to support an option called restartdelay:

extra_commands - Command is available with the service in any state
extra_started_commands - Command is available when the service is started
extra_stopped_commands - Command is available when the service is stopped

コード Example definition of restartdelay method

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

重要
The restart() function cannot be overridden in OpenRC!

Service configuration variables

In order to support configuration files in /etc/conf.d/, no specifics need to be implemented: when the init script is executed, the following files are automatically sourced (i.e. the variables are available to use):

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

Also, if the init script provides a virtual dependency (such as net), the file associated with that dependency (such as /etc/conf.d/net) will be sourced too.

Changing runlevel behavior

Who might benefit

Many laptop users know the situation: at home they need to start net.eth0, but they don't want to start net.eth0 while on the road (as there is no network available). With Gentoo the runlevel behavior can be altered at will.

For instance, a second "default" runlevel can be created, with other init scripts assigned to it. At boot time, the user can select what "default" runlevel to use.

Using softlevel

First of all, create the runlevel directory for the second "default" runlevel. As an example we create the offline runlevel:

root #mkdir /etc/runlevels/offline

Add the necessary init scripts to the newly created runlevel. For instance, to have an exact copy of the current default runlevel but without 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 |

Even though net.eth0 has been removed from the offline runlevel, udev might want to attempt to start any devices it detects and launch the appropriate services, functionality that is called hotplugging. By default, Gentoo does not enable hotplugging.

To enable hotplugging, but only for a selected set of scripts, use the rc_hotplug variable in /etc/rc.conf:

ファイル /etc/rc.confEnable hotplugging of the WLAN interface

rc_hotplug="net.wlan !net.*"

メモ
For more information on device initiated services, please see the comments inside /etc/rc.conf.

Edit the bootloader configuration and add a new entry for the offline runlevel. In that entry, add softlevel=offline as a boot parameter.

Using bootlevel

Using bootlevel is completely analogous to softlevel. The only difference here is that a second "boot" runlevel is defined instead of a second "default" runlevel.

環境変数

はじめに

環境変数とは、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"

← Initscript system Home ファイルとディレクトリ →

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

Gentoo Linux sparc ハンドブック: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 を検証する

Runlevels

Booting the system

Initscripts

How init works

Available runlevels

Working with initscripts

Updating runlevels

rc-update

Adding and removing services

Configuring services

Why additional configuration is needed

conf.d directory

Writing initscripts

Is it necessary?

Layout

Dependencies

Virtual dependencies

Controlling the order

Standard functions

Adding custom options

Service configuration variables

Changing runlevel behavior

Who might benefit

Using softlevel

Using bootlevel

環境変数

はじめに

重要な例

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