Gentoo Linux hppa ハンドブック:Gentoo での作業
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 ファイル内で設定できます。次の例はデフォルト値を示しています:
ACCEPT_LICENSE="-* @FREE"
この設定の下では、自由ソフトウェアライセンスあるいは自由な文書ライセンスが設定されているパッケージがインストール可能となります。フリーではないソフトウェアはインストールできなくなります。
ACCEPT_LICENSE は /etc/portage/make.conf 内でグローバルに設定することもできますし、/etc/portage/package.license ファイル内でパッケージ毎に定義することもできます。
たとえば、google-chrome ライセンスを www-client/google-chrome パッケージのために許可するには、/etc/portage/package.license に次の内容を追加してください:
www-client/google-chrome google-chrome
これにより www-client/google-chrome パッケージのインストールは許可しますが、同じライセンスを持っていたとしても www-plugins/chrome-binary-plugins パッケージのインストールは禁止されます。
または、よく必要になる sys-kernel/linux-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 グループ内のライセンスのみを受諾取り消ししてください:
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インストールは、システムが通常通り機能するために必要な、パッケージのリストを含む情報を格納している特定のプロファイルに従っています。
ブロックされたパッケージ
[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 のバグトラッキングシステムにバグを報告してください。
マスクされたパッケージ
!!! 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 | アプリケーションはターゲットアーキテクチャ上で動作しません。これが正しくなければ、バグを提出してください。 |
missing keyword | アプリケーションはまだターゲットアーキテクチャ上でテストされていません。アーキテクチャ移植チームにパッケージのテストを依頼するか、彼らのためにテストして Gentoo の Bugzilla のウェブサイトで知見を報告してください。/etc/portage/package.accept_keywords および特定のパッケージに対してキーワードを許可するも参照してください。 |
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 (webchat) (IRC) で聞いてください。まだであれば、遠慮なく壊れた ebuild のためにバグを提出してください。
バグが修正されたら、Gentoo ebuild リポジトリを再同期して修正されたダイジェストを引っ張ってきてください。
Gentoo ebuild リポジトリを一日一回以上同期しないように気をつけてください。公式の Gentoo ネチケットポリシーに書かれている通り(また emerge --sync を実行したときにも表示される通り)、あまりにも頻繁に同期するユーザは当面の間、それ以上の同期を禁止されます。このポリシーにも繰り返し違反する悪用者は完全にアクセスを禁止されることがあります。再同期が Gentoo の rsync ミラーに過剰な負荷を与えないようにするために、どうしても必要な場合を除いて 24 時間周期で同期されるのを待つのが最善です。
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で定義できます:
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 をサポートするには:
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フラグ設定を通じて有効にする)には:
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 の機能
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
と設定します:
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つです。
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にある場合:
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に追加してください:
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
このページの内容は 適切なプロファイルを選ぶで systemd プロファイルを選択したユーザには適用されません。
ランレベル
システムの起動
システムが起動すると、たくさんのテキストが流れます。注意して見ると、(通常) それが毎回同じ内容であることに気づくでしょう。これら全てのアクションの実行はブートシーケンスと呼ばれ、(ほぼ) 静的に定義されます。
まずブートローダーが、ブートローダーの設定で定義されたカーネルイメージを読み込みます。そしてブートローダーはCPUにカーネルを実行するよう指示します。カーネルが読み込まれ実行されると、全てのカーネル内の構造やタスクが初期化され、initプロセスを開始します。
このプロセスではまず (/etc/fstab に書かれた) すべてのファイルシステムをマウントし、使用可能な状態にします。そして /etc/init.d/ に置かれたいくつかのスクリプトを実行します。これらのスクリプトは、システムのブートに必要なサービスを立ち上げます。
全てのスクリプトを実行したら、initは最後に端末 (ほとんどの場合 Alt+F1 や Alt+F2 などの下に隠された仮想端末ですが) を agetty と呼ばれる特別なプロセスに接続します。このプロセスは login を実行することで各端末からユーザーがログオンできるようにします。
Initscripts
ところで、initは /etc/init.d/ 内のスクリプトを適当に実行するわけではありません。それどころか、/etc/init.d/ 内のスクリプトを全て実行するわけでもなく、指示されたスクリプトだけを実行します。実行するスクリプトは /etc/runlevels/ を見て決定しています。
まずinitは /etc/init.d/ にあるスクリプトのうち、/etc/runlevels/boot/ にシンボリックリンクが存在するものを全て実行します。基本的にはアルファベット順に開始しますが、一部のスクリプトは自身の前に開始しなければならないスクリプトを示す依存情報を持っています。
/etc/runlevels/boot/ から参照されている全てのスクリプトを実行すると、続けてinitは /etc/runlevels/default/ にシンボリックリンクが存在するスクリプトを実行します。繰り返しになりますが、正しい起動シーケンスのために順序を変更する依存情報をスクリプトが持っていない限り、アルファベット順でスクリプトの実行順が決まります。これは Gentoo Linux のインストールで実行した rc-update add sshd default などのコマンドで default
を使った理由でもあります。
init の仕組み
もちろん、init 自身がこれらすべてを決定するわけではありません。どのような動作をすべきか指定する設定ファイルが必要です。この設定ファイルが /etc/inittab です。
先ほど説明したブートシーケンスを思い出してください - init が最初にする動作はすべてのファイルシステムをマウントすることです。これは /etc/inittab の以下の行で定義されています:
si::sysinit:/sbin/openrc sysinit
この行は init に対し、システムを初期化するために /sbin/openrc sysinit を実行するよう指示します。/sbin/openrc スクリプトが初期化を処理するので、init はあまり多くのことをしないと言えるかもしれません - システム初期化のタスクは他のプロセスに委譲しているのです。
第二に、init は /etc/runlevels/boot/ にシンボリックリンクがあるすべてのスクリプトを実行します。これは以下の行で定義されています:
rc::bootwait:/sbin/openrc boot
再び OpenRC スクリプトが必要なタスクを処理します。OpenRC に渡されるオプション (boot) が、使用する /etc/runlevels/ のサブディレクトリと同じであることに注目してください。
ここで、init はどのランレベルを実行すべきか見るために設定ファイルを調べます。これを決定するために /etc/inittab から以下の行が読み込まれます:
id:3:initdefault:
この場合(Gentoo ユーザーの多くはこれを使用しています)、ランレベルの id は3です。この情報を使って、init はランレベル3を開始するために何を実行する必要があるかを調べます:
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 はどの仮想コンソールを有効化すべきか、また各コンソールでどのコマンドを実行しなければならないかを決定します:
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
有効なランレベル
前の節では、init がどのランレベルを有効化するか決めるために番号を用いていることを説明しました。ランレベルはシステムが動作する際の状態であり、ランレベルを開始したり終了したりした時に実行されるスクリプト(ランレベルスクリプトあるいは init スクリプト)の一群を含んでいます。
Gentoo では7つのランレベルが定義されています: 3つの内部ランレベルと4つのユーザー定義ランレベルです。内部ランレベルはそれぞれ sysinit、shutdown そして reboot と呼ばれており、まさに名前が示す通りに動作します: システムの初期化、システムのパワーオフ、そしてシステムの再起動を行うのです。
ユーザー定義ランレベルはそれぞれ付随する /etc/runlevels/ のサブディレクトリーを持ちます: boot、default、nonetwork そして single です。boot ランレベルは、他のランレベルによって使用される、システムに必要なすべてのサービスを起動します。残りの3つのランレベルは開始するサービスに違いがあります: default は日常的な作業に使われ、nonetwork は一切のネットワーク接続が不要な場合に使われ、そして single はシステムを修復する必要がある時に使われます。
init スクリプトの使い方
openrc プロセスが開始するスクリプトは init スクリプトと呼ばれます。/etc/init.d/ 内の各スクリプトは start
、stop
、restart
、zap
、status
、ineed
、iuse
、iwant
、needsme
、usesme
あるいは wantsme
という引数で実行することができます。
サービス(およびすべての依存サービス)を開始、停止、あるいは再起動するには、start
、stop
および restart
引数を使います:
root #
rc-service postfix start
指定されたサービスを必要(need)とするサービスのみが停止または再起動されます。その他の依存サービス(指定されたサービスを使用(use)するが必要(need)としないもの)は影響されません。
あるサービスを停止するが依存サービスは停止させたくない場合には、stop
引数とともに --nodeps
オプションも使用します:
root #
rc-service --nodeps postfix stop
サービスがどのような状態にあるか(started、stopped、 ...)見るには status
引数を使用します:
root #
rc-service postfix status
サービスが実行中であるというステータス情報が表示されたのに実際はそうでない場合には、zap
引数を使用してステータス情報を "stopped" にリセットします:
root #
rc-service postfix zap
サービスがどのような依存関係を持っているか問い合わせるには、iwant
、iuse
あるいは ineed
引数を使用します。ineed
を使うとそのサービスが正しく機能するために本当に必要なサービスが表示されます。一方 iwant
や iuse
は、そのサービスから使用することができるけれども、正しく機能する上で必要というわけではないサービスを表示します。
root #
rc-service postfix ineed
同じように、そのサービスを必要としているサービス(needsme
)やそのサービスを使用できるサービス(usesme
または wantsme
)を問い合わせることもできます:
root #
rc-service postfix needsme
ランレベルの更新
rc-update
Gentoo の init システムはまずどのサービスを開始する必要があるかを決めるために依存関係ツリーを使用しています。これはユーザーに手動でやってもらうには退屈な作業なので、ランレベルや init スクリプトの管理を簡略化するツールが作成されました。
rc-update を使って init スクリプトをランレベルに追加したり削除することができます。rc-update ツールはその後自動的に depscan.sh スクリプトを使って依存関係ツリーを再構築します。
サービスの追加と削除
これまでの説明では init スクリプトはすでに "default" ランレベルに追加されていました。"default" の意味するところはこの文書の前の方で説明しました。ランレベルの他に、rc-update スクリプトは動作を定義する第二の引数を必要とします: add
、del
または show
です。
init スクリプトを追加または削除するには、rc-update に add
または del
引数、その後に init スクリプトとランレベルを渡します。一例:
root #
rc-update del postfix default
rc-update -v show コマンドは利用可能なすべての init スクリプトと、それらが実行されるランレベルの一覧を出力します:
root #
rc-update -v show
rc-update show を(-v
引数なしで)実行して有効になっている init スクリプトとそのランレベルのみを表示させることもできます。
サービスの設定
追加の設定が必要な理由
init スクリプトはとても複雑です。したがって、ユーザーに init スクリプトを直接編集してもらうのは間違いを起こしやすくなり必ずしも合理的ではありません。しかしながら、サービスを設定できるということは重要です。たとえば、ユーザーがサービス自体により多くのオプションを渡したい場合があるでしょう。
init スクリプトの外部に設定を持つ第二の理由は、ユーザーの設定変更を取り消してしまうおそれなしに init スクリプトを更新できるということです。
conf.d ディレクトリ
Gentoo はこうしたサービスを設定する簡単な方法を提供しています: 設定可能なすべての init スクリプトは /etc/conf.d/ にファイルを持ちます。たとえば、apache2 init スクリプトは /etc/conf.d/apache2 という設定ファイルを持っており、これには Apache2 サーバーに起動時に渡すオプションを含めることができます:
APACHE2_OPTS="-D PHP5"
こうした設定ファイルは(/etc/portage/make.conf のように)変数のみ を含んでおり、サービスの設定を非常に容易にします。また、これにより変数について(コメントとして)より多くの情報を提供できるようになっています。
init スクリプトを書く
有用な資料として OpenRC の service script guide もあります。
これは必要な作業なんですか?
いいえ、Gentoo は提供しているすべてのサービスについてそのまま使える init スクリプトを提供しているので、通常は init スクリプトを書く必要はありません。しかしながら、一部のユーザーは Portage を使わずにサービスをインストールしているかもしれません。このような場合にはたいてい init スクリプトを作成しなければなりません。
サービスによって提供されている init スクリプトは、明示的に Gentoo 用に書かれているのでなければ使用してはいけません: Gentoo の init スクリプトは他のディストリビューションで使われている init スクリプトとは互換性がありません! そのディストリビューションが OpenRC を使っているのでない限りは、ということですが!
レイアウト
init スクリプトの基本構造は以下の通りです。
#!/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 の依存情報を見てみましょう:
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 サービスを見てみましょう。
depend() {
need net
before inetd
before xinetd
}
同じランレベルのすべてのサービスを表す "*" グロブを使うこともできますが、これは推奨されません。
depend() {
before *
}
サービスがローカルディスクに書き込む必要があるなら、localmount を need にするべきです。サービスが /var/run/ に PID ファイルといったものを配置する場合は 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-daemon
Gentoo の 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 変数を使います:
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(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 という名前のファイルが作成されます:
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 という名前のファイルを作成してそこに定義を入れてください:
http_proxy="proxy.server.com:8080"
カスタマイズされるすべての環境変数について同じファイルを使うことで、システム管理者は自身が定義した変数を素早く見ることができます。
env-update
/etc/env.d/ ディレクトリ内のいくつかのファイルは PATH 変数に定義を追加しています。これは間違いではありません: env-update コマンドは実行されると、いくつかの定義を結合してそれぞれの環境変数をアトミックに更新します。これによって、パッケージ (やシステム管理者) が自身の環境変数の設定をすでに存在する値と干渉しないように追加するのが簡単になります。
env-update スクリプトは値を /etc/env.d/ にあるファイルのアルファベット順で結合します。ファイル名は2桁の10進数で始めないといけません。
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 (ログインシェルセッションに対して) を使用します:
# 後ろにディレクトリーが続かないコロンは現在の作業ディレクトリーとして扱われます
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 hppa ハンドブック:Gentoo での作業" overrides earlier display title "ハンドブック:HPPA/フル/ワーキング".