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

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

Portage におけるファイル

設定ディレクティブ

Portage にはデフォルト設定があり、それらは /usr/share/portage/config/make.globals に保管されています。すべての Portage の設定は変数を通じて処理されます。Portage がどのような変数を見ているか、またそれらがどのような意味を持つのかについては後ほど説明します。

多くの設定ディレクティブはアーキテクチャーによって異なるので、Portage はシステムプロファイルの一部であるデフォルト設定ファイルも持っています。このプロファイルは /etc/portage/make.profile シンボリックリンクによって指定されています; Portage の設定はプロファイルとそのすべての親プロファイルの make.defaults ファイルでセットされています。プロファイルと /etc/portage/make.profile ディレクトリーについては後ほど詳しく説明します。

設定変数を変更する際は /usr/share/portage/config/make.globals や make.defaults を書き換えないでください。代わりに、これらのファイルよりも優先される /etc/portage/make.conf を使用してください。詳細については /usr/share/portage/config/make.conf.example を読んでください。名前が示すとおり、これは単なるサンプルファイルです - Portage はこのファイルを読み込みません。

また Portage の設定変数を環境変数として定義することもできますが、これはお勧めしません。

profile 特有の情報

すでに /etc/portage/make.profile というディレクトリーが出てきました。さて、実際にはこれはディレクトリーではなくてプロファイルへのシンボリックリンクで、デフォルトでは /var/db/repos/gentoo/profiles/ の中の1つを指していますがお好きな場所にプロファイルを作成してそれを指定することもできます。このシンボリックリンクが指すプロファイルが、システムが従うプロファイルになります。

プロファイルは、そのプロファイルに該当するシステムに属するパッケージの一覧やそのプロファイルでは動かない(またはマスクされた)パッケージの一覧など、アーキテクチャー特有のPortage 用の情報を含んでいます。

ユーザーによる設定

Portage の動作をソフトウェアのインストールを考慮して変更する必要がある時には、/etc/portage/ 内の適切なファイルを変更する必要があります。/etc/portage/ 内のファイルを使うことを強くお勧めします、環境変数を通じて動作を上書きするのはできる限り避けてください！

/etc/portage/ の中では、ユーザーは以下のファイルを作成することができます:

package.mask Portage が決してインストールしようとすべきでないパッケージの一覧。
package.unmask Gentoo 開発者がユーザーにできる限り emerge しないよう勧めているにも関わらず Portage がインストールできるパッケージの一覧。
package.accept_keywords パッケージがそのシステムやアーキテクチャにおいて適切だと(まだ)判断されていないにも関わらず Portage がインストールできるパッケージの一覧。
package.use システム全体では使われていないが特定のパッケージでは使われる USE フラグの一覧。

これらはファイルである必要はありません; パッケージごとのファイルを含むディレクトリーにすることもできます。/etc/portage/ ディレクトリーについてのさらなる情報や作成できるファイルの完全な一覧が Portage の man ページにあります:

user $man portage

Portage のファイルやディレクトリーの場所を変更する

これまでに言及した設定ファイルを他の場所に置くことはできません - Portage は常に正確にそれらの場所にあるそれらのファイルを見にいきます。しかしながら、Portage はこれ以外に多くの場所をさまざまな目的のために使っています: ビルドディレクトリー、ソースコードの保管場所、Gentoo リポジトリの場所、…

これらの目的についてはどれもよく知られたデフォルトの場所がありますが、それらは個人の好みに応じて /etc/portage/make.conf で変更することができます。この章の残りの部分では、Portage がどのような特別な目的の場所を使っているか、またそれらのファイルシステム上の配置を変更する方法について説明します。

ただし、この文書はリファレンスとして使われることを意図したものではありません。すべてを網羅している文書が必要な場合は Portage や make.conf の man ページを参照してください:

user $

man portage

user $man make.conf

ファイルの保存

Gentoo ebuild リポジトリ

Gentoo ebuild リポジトリのデフォルトの場所は /var/db/repos/gentoo です。これは /usr/share/portage/config/repos.conf にあるデフォルトの repos.conf ファイルで定義されています。デフォルト値を変更するには、このファイルを /etc/portage/repos.conf/gentoo.conf にコピーしてから location 設定を変更してください。(この変数を書き換えて) Gentoo ebuild リポジトリをデフォルト以外の場所に保存する場合、/etc/portage/make.profile シンボリックリンクをそれに応じて変更することを忘れないでください。

/etc/portage/repos.conf/gentoo.conf の location 設定を変更した後には、location の変更が適用されない /etc/portage/make.confの以下の変数についても同様に書き換えることをお勧めします。これは Portage が変数を処理する方法に起因します: PKGDIR、DISTDIR、および RPMDIR。

ビルド済バイナリ

Portage はデフォルトではビルド済みバイナリを使用しませんが、それらを広範にサポートしています。Portage にビルド済みバイナリを使用するよう指示すると、Portage はバイナリパッケージを /var/cache/binpkgs から探します。この場所は PKGDIR 変数で定義されています。

ソースコード

アプリケーションのソースコードはデフォルトで /var/cache/distfiles に保管されます。この場所は DISTDIR 変数で定義されています。

Portage のデータベース

Portage はシステムの状態(どのパッケージがインストールされているか、どのファイルがどのパッケージに属しているか、…)を /var/db/pkg に保管しています。

警告
システム状態ファイルを手動で置き換えないでください！ Portage のシステムに関する情報が壊れる可能性があります。

Portage のキャッシュ

Portage のキャッシュ (変更時間、virtual、依存関係ツリーの情報、…を含む) は /var/cache/edb に保管されています。この場所は本当にキャッシュです: その時に Portage に関係するアプリケーションが実行されていない限り、ユーザーはこの場所のキャッシュを削除できます。

ソフトウェアをビルドするにあたり

Portage の一時ファイル

Portage の一時ファイルはデフォルトで /var/tmp/ に保管されています。これは PORTAGE_TMPDIR 変数で定義されています。

ビルド作業用ディレクトリ

Portage は各パッケージについて /var/tmp/portage/ 内に個別にビルドディレクトリーを作成しそこで emerge を行います。この場所は PORTAGE_TMPDIR 変数に portage/ を付け加えることで定義されます。

ライブファイルシステムの場所

デフォルトでは Portage はすべてのファイルを現在のファイルシステム (/) にインストールしますが、これは ROOT 環境変数を定義することで変更できます。これは新しいビルドイメージを作る際に有用です。

ログ記録機能

ebuild のログ記録

Portage は ebuild ごとのログファイルを作成することができますが、これは PORT_LOGDIR 変数に Portage から (Portage ユーザーを通じて) 書き込み可能な場所がセットされている場合のみ行われます。デフォルトではこの変数はセットされていません。PORT_LOGDIR がセットされていない場合には現在のログシステムではビルドログは一切作成されませんが、ユーザーは新しい elog サポートによるログを受け取るかもしれません。

PORT_LOGDIR が定義されておらず elog が使用されている場合、elog によって保存されるビルドログその他すべてのログが以下で説明するとおりに利用可能になります。

Portage は elog の使用を通じてログの記録に対するきめ細かい制御を提供します:

PORTAGE_ELOG_CLASSES: どのような種類のメッセージを記録するか定義できるところです。info、warn、error、log、および qa のスペース区切りのあらゆる組み合わせが指定できます。
- info: ebuild によって出力される "einfo" メッセージを記録します
- warn: ebuild によって出力される "ewarn" メッセージを記録します
- error: ebuild によって出力される "eerror" メッセージを記録します
- log: いくつかの ebuild で見られる "elog" メッセージを記録します
- qa: ebuild によって出力される "QA Notice" メッセージを記録します

PORTAGE_ELOG_SYSTEM: ログメッセージを処理するモジュールを選択します。空のままになっているとログの記録は無効になります。save、custom、syslog、mail、save_summary、および mail_summary のスペース区切りのあらゆる組み合わせが使用できます。elog を使用するには少なくとも1つのモジュールを使用する必要があります。
- save: パッケージごとに1つのログを $PORT_LOGDIR/elog、または $PORT_LOGDIR が定義されていなければ /var/log/portage/elog に保存します。
- custom: すべてのメッセージをユーザーが $PORTAGE_ELOG_COMMAND で定義したコマンドに渡します; これについては後で説明します。
- syslog: すべてのメッセージをインストールされているシステムロガーに送信します。
- mail: すべてのメッセージをユーザーが $PORTAGE_ELOG_MAILURI で定義したメールサーバーに渡します; これについては後で説明します。elog のメール機能には >=portage-2.1.1 が必要です。
- save_summary: save と似ていますが、これはすべてのメッセージを $PORT_LOGDIR/elog/summary.log、または $PORT_LOGDIR が定義されていなければ /var/log/portage/elog/summary.log に統合します。
- mail_summary: mail と似ていますが、これは emerge が終了した時にすべてのメッセージを1通のメールで送信します。

PORTAGE_ELOG_COMMAND: custom モジュールが有効になっている場合のみ使われます。ユーザーはログメッセージを処理するコマンドを指定できます。コマンドでは2つの変数を利用できることに留意してください: ${PACKAGE} がパッケージ名およびバージョン、${LOGFILE} がログファイルの絶対パスです。例:

コード PORTAGE_ELOG_COMMAND の定義例

PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"

PORTAGE_ELOG_MAILURI: アドレス、ユーザー、パスワード、メールサーバー、ポート番号などの mail モジュールのための設定を含みます。デフォルト設定は "root@localhost localhost" です。以下はユーザー名とパスワード認証が必要な特定のポート(デフォルトは25番ポート)上の SMTP サーバー用の例です:

コード PORTAGE_ELOG_MAILURI の定義例

PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"

PORTAGE_ELOG_MAILFROM: ログメールの "from" アドレスをセットできます; セットされていない場合はデフォルトの "Portage" が使われます。

PORTAGE_ELOG_MAILSUBJECT: ログメールの件名欄を作成できます。2つの変数が利用可能なことに留意してください: ${PACKAGE} はパッケージ名およびバージョンを表示し、${HOST} は Portage が実行されているホストの完全修飾ドメイン名を表示します。例:

コード PORTAGE_ELOG_MAILSUBJECT の定義例

PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST} with some messages"

重要
Portage-2.0.* で enotice を使用していたユーザーは、elog と互換性がないため enotice を完全に削除する必要があります。

← 環境変数 Home 変数 →

Portage の設定

前に触れたように、Portage は多くの変数を通じて設定することができます。これらは /etc/portage/make.conf か、または /etc/portage/ のサブディレクトリのどれかで定義する必要があります。さらなる網羅的な情報については make.conf や portage の man page を参照してください:

user $

man make.conf

user $man portage

ビルドに特有のオプション

configure とコンパイラーのオプション

Portage がアプリケーションをビルドする場合には、以下の変数の内容をコンパイラーや configure スクリプトに渡します:

CFLAGS と CXXFLAGS: C や C++ のコンパイルに使いたいコンパイラーフラグを定義します。
CHOST: アプリケーションの configure スクリプト向けにビルドホストの情報を定義します。
MAKEOPTS: make コマンドに渡されます。通常は、コンパイルの際に使用される並列処理の数を定義するようにセットされます。make のオプションについての詳細は make の man page で見つけられます。

USE 変数も configure やコンパイルの間に使用されますが、これについては以前の章で詳しく説明しました。

マージのオプション

Portage はあるソフトウェアタイトルの新しいバージョンをマージし終わると、古いバージョンの使われなくなったファイルをシステムから削除します。Portage は古いバージョンを unmerge する前にユーザーに5秒間の猶予を与えます。この5秒は CLEAN_DELAY 変数によって定義されています。

EMERGE_DEFAULT_OPTS をセットすることで、emerge が実行される際にいつも特定のオプションを使用させることができます。便利なオプションは --ask、--verbose、--tree などです。

設定ファイルの保護

Portage によって保護される場所

Portage は、ファイルが保護された場所に格納されていない場合、ソフトウェアタイトルの新しいバージョンによって提供されたファイルを上書きします。これらの保護された場所は CONFIG_PROTECT 変数によって定義されており、一般的には設定ファイルの場所です。ディレクトリのリストはスペースで区切られています。

このような保護された場所に書き込まれるファイルはリネームされ、ユーザーは新しいバージョンの(おそらくは)設定ファイルの存在について警告されます。

現在の CONFIG_PROTECT の設定について調べるには、emerge --info の出力を使います:

user $emerge --info | grep 'CONFIG_PROTECT='

Portage の設定ファイル保護についてのさらなる情報は、emerge の manpage の CONFIGURATION FILES 節にあります。

user $man emerge

ディレクトリを除外する

保護された場所の一定のサブディレクトリを 'unprotect' したい場合、ユーザーは CONFIG_PROTECT_MASK 変数を利用できます。

ダウンロードオプション

サーバーの場所

要求された情報やデータがシステムにない場合、Portage はそれをインターネットから取得します。さまざまな情報やデータチャンネルのサーバーの場所は、以下の変数によって定義されています:

GENTOO_MIRRORS: ソースコード(distfiles)を含むサーバーの場所のリストを定義します。
PORTAGE_BINHOST: そのシステム向けのビルド済みパッケージを含む特定のサーバーの場所を定義します。

第三の設定は、ユーザーがローカル Gentoo リポジトリを更新するのに使う rsync サーバーの場所に関するものです。これは /etc/portage/repos.conf ファイル(または、ディレクトリとして定義されている場合にはそのディレクトリの中のファイル)に定義されています:

sync-type: サーバーの種類を定義しており、デフォルトは rsync です。
sync-uri: Portage が Gentoo リポジトリを取得するのに使う特定のサーバーを定義します。

GENTOO_MIRRORS、sync-type、および sync-uri 変数は mirrorselect アプリケーションを通して自動的にセットできます。もちろん、使用する前にまず app-portage/mirrorselect がインストールされている必要があります。詳細については mirrorselect のオンラインヘルプを参照してください:

root #mirrorselect --help

プロキシサーバーの使用が必要な環境では http_proxy、ftp_proxy、および RSYNC_PROXY 変数を定義できます。

フェッチコマンド

Portage がソースコードを取得する必要がある場合、デフォルトでは wget を使用します。これは FETCHCOMMAND 変数を通して変更できます。

Portage は部分的にダウンロードされたソースコードの取得を再開することができます。デフォルトでは wget を使用しますが、これは RESUMECOMMAND 変数を通して置き換えることができます。

FETCHCOMMAND や RESUMECOMMAND がソースコードを正しい場所に格納することを確認してください。これらの変数の中では、\${URI} および \${DISTDIR} 変数を使用してソースコードの場所と distfiles の場所をそれぞれ示すことができます。

また、FETCHCOMMAND_HTTP、FETCHCOMMAND_FTP、RESUMECOMMAND_HTTP、RESUMECOMMAND_FTP などでプロトコルごとのハンドラーを定義することもできます。

rsync の設定

Portage が Gentoo リポジトリの更新に使用する rsync コマンドは置き換えることができませんが、rsync コマンドに関するいくつかの変数をセットすることは可能です:

PORTAGE_RSYNC_OPTS: 同期の間に使用される多くのデフォルト変数をセットします。各変数はスペース区切りです。これらは、自分が何をしているのか正確に分かっているのでない限り変更すべきではありません。一定の絶対に必要なオプションについては、たとえ PORTAGE_RSYNC_OPTS が空であっても常に使用されることに注意してください。

PORTAGE_RSYNC_EXTRA_OPTS

同期の際の追加オプションをセットするのに使われます。各オプションはスペースで区切られている必要があります:

--timeout=<number>: rsync が接続をタイムアウトしたとみなす前に rsync 接続が待機できる秒数を定義します。この変数のデフォルトは 180 ですが、ダイヤルアップ接続のユーザーや遅いコンピューターを使う個人はこれを 300 かそれ以上にセットしたくなるかもしれません。
--exclude-from=/etc/portage/rsync_excludes: rsync が更新プロセス中に無視すべきパッケージやカテゴリをリストしたファイルを指定します。この例では、/etc/portage/rsync_excludes を指定しています。
--quiet: 画面への出力を減らします。
--verbose: 完全なファイルリストを出力します。
--progress: 各ファイルについて進捗メーターを表示します。

PORTAGE_RSYNC_RETRIES: rsync が SYNC 変数で指定されたミラーから手を引く前に接続を試みる回数を定義します。この変数のデフォルトは 3 です。

これらのオプションやその他の詳細については man rsync を読んでください。

Gentoo の設定

ブランチの選択

ACCEPT_KEYWORDS 変数を使ってデフォルトのブランチを変更することができます。デフォルトはアーキテクチャの stable ブランチです。Gentoo のブランチについては次の章に詳細な情報があります。

Portage の機能

FEATURES 変数を通じて、一定の portage の機能を有効化できます。Portage の機能については以前の章で説明しました。

Portage の挙動

リソースの管理

PORTAGE_NICENESS 変数により、ユーザーは Portageが実行中に使用する nice 値を増加させたり減少させたりできます。PORTAGE_NICENESS の値は Portage の現在の nice 値に加算されます。

nice 値についての詳細は、Portage niceness と nice の man ページを見てください:

user $man nice

出力の動作

NOCOLOR 変数は Portage が色付きの出力の使用を無効化すべきかを定義しており、デフォルトは false です。

← ファイルとディレクトリ Home ソフトウェアのブランチを併用する →

1つのブランチを使う

stable

ACCEPT_KEYWORDS 変数はシステムのソフトウェアブランチを定義しています。この変数は /etc/portage/make.conf ファイル内で設定され、デフォルトでは stable ブランチに設定されます。この場合、デフォルト値は ppc です。

ファイル /etc/portage/make.confstable ブランチを使用する

# 次の値はデフォルトで設定され、明示的に定義する必要は_ありません_。
ACCEPT_KEYWORDS="ppc"

より簡単な体験のために、そして不安定化等の問題のリスクがより低いことから、ハンドブックとしては stable ソフトウェアブランチを使い続けることをおすすめします。これは Portage のデフォルトの挙動なので何も変更する必要はありません。危険に生きたい、あるいは可能な限り最新のソフトウェア更新を受け取りたいシステム管理者は、testing の節を読むべきです。

testing

警告
Hic sunt dracones! Running software from the testing branch may incur stability issues, imperfect package handling (for instance wrong/missing dependencies), frequent ebuild revisions (resulting in a lot of compiling) or packages that are broken in a other, often unexpected, manner. System administrators who are less comfortable with Gentoo or Linux in general should avoid the testing branch. As noted previously, the Handbook recommends staying with the stable, more thoroughly tested branch.

あまりテストされていないソフトウェアスタックを運用し、その代わりに「最先端」の更新を受け取りたいシステム管理者は、testing ブランチを選択することができます。testing ブランチに切り替えるには、ACCEPT_KEYWORDS の値を ~ppc に設定してください。

ファイル /etc/portage/make.conftesting ブランチを使用する

# amd64 アーキテクチャに対して testing ブランチ (~) を使用するように、Portage に指示します。
ACCEPT_KEYWORDS="~ppc"

Gentoo プロジェクトによってサポートされているすべてのアーキテクチャは、アーキテクチャの ACCEPT_KEYWORDS 値の前に単に ~ (チルダ記号) を追加することで testing ブランチに移行することができます。

testing ブランチはまさにその名前から期待される通り、不安定版です。パッケージが testing ブランチにある場合、それは開発者がそのパッケージは機能すると信じているけれども未だ徹底的にはテストされていないということを意味します。testing ブランチを使用しているシステムはパッケージのバグの最初の遭遇者となる可能性があります。バグを発見した場合は、開発者がそのバグに気づけるようにバグ報告を提出してください。

stable から testing にブランチを変更して @world 更新を実行したときに、大量の、ときとして数百のパッケージが利用可能な最新のバージョンに更新されるのは普通のことです。更新は一般にプロジェクト上流の現行版リリースに対応します。stable から testing ブランチに移行した後に、stable ブランチへ戻るのは困難と判明するかもしれないことを心に留めておいてください。これは想定内のことです。

stable と testing を併用する

package.accept_keywords

個々のパッケージについては testing ブランチを許可し、システムの残りの部分には stable ブランチを使うように Portage を設定することができます。これを実現するには、パッケージのカテゴリと名前を /etc/portage/package.accept_keywords ファイル内に追加します。また、(同名の) ディレクトリを作成してその下のファイルにパッケージをリストアップすることも可能です。

たとえば、gnumeric で testing ブランチを使用するには:

ファイル /etc/portage/package.accept_keywordsgnumeric アプリケーションについては testing ブランチを使用する

app-office/gnumeric

特定のバージョンをテストする

testing ブランチの特定のソフトウェアバージョンを使用する一方で、その後のバージョンについては testing ブランチからの更新を許可しないようにするために、パッケージの特定のバージョンを package.accept_keywords ファイル内で定義することができます。特定のバージョンを定義するには、= 演算子を活用できます。<=、<、> あるいは >= 演算子を使って、バージョンの範囲を入力することもできます。

いかなる場合でも、パッケージバージョン情報を定義する際には演算子を使わなければなりません。バージョン情報がなければ演算子は使用できません。

以下の例では、gnumeric の特定のバージョン (バージョン 1.2.13) のインストールを、たとえそれが testing ブランチにある場合でも許可するように、Portage に指示しています:

ファイル /etc/portage/package.accept_keywordsgnumeric パッケージの特定のバージョンの選択を許可する

=app-office/gnumeric-1.2.13

マスクされたパッケージ

package.unmask

重要
Gentoo 開発者は正当な理由でパッケージをマスクしているので、一般論としてパッケージのアンマスクは Gentoo のサポートチャンネルでサポートすることができません。そのため package.unmask や package.mask に関するサポートリクエストは、無視されるか WONTFIX としてマークされることも十分考えられます。パッケージをアンマスクするときには十分注意を払ってください。

次の例では、パッケージが Gentoo 開発者によってマスクされていると仮定します。パッケージをインストールしようとするときに、Portage はパッケージがマスクされていることを示すメッセージを出力し、さらに通常はそのマスクの理由を提供するでしょう。次に、package.mask ファイル (デフォルトでは /var/db/repos/gentoo/profiles/ にあります) に書かれている理由にも関わらず、システム管理者はそれでもこのパッケージをインストールしたいとします。

これを行うために、システム管理者は対象のパッケージバージョン (通常はプロファイルの package.mask ファイルとまったく同じ 1 行) を /etc/portage/package.unmask の場所に追加することができます。

たとえば =mail-client/mutt-2.2.9 がマスクされている場合、まったく同じ 1 行を package.unmask の場所に追加することでアンマスクできます:

ファイル /etc/portage/package.unmaskパッケージの特定のバージョンをアンマスクする

=mail-client/mutt-2.2.9

メモ
/var/db/repos/gentoo/profiles/package.mask のエントリーにパッケージのバージョンの範囲が含まれている場合、実際に必要なバージョンのみをアンマスクする必要があります。演算子を使用してバージョンを指定する方法については前の節をお読みください。

package.mask

特定のパッケージをインストールしたり、あるパッケージを特定のバージョンへ更新したりしないように、Portage に指示することもできます。このことを、パッケージをマスクするといいます。パッケージをマスクするには、必要に応じた修飾子を /etc/portage/package.mask の場所 (そのファイル、またはそのディレクトリの中のファイルのどちらか) に追加してください。

たとえば Portage に gentoo-sources-4.9.16 よりも新しいカーネルソースをインストールさせないようにするには、package.mask の場所に以下の行を追加します:

ファイル /etc/portage/package.mask4.9.16 よりも新しいバージョンの sys-kernel/gentoo-sources をマスクする

>sys-kernel/gentoo-sources-4.9.16

← 変数 Home 追加ツール →

dispatch-conf

dispatch-conf は ._cfg0000_<name> ファイルのマージに役立つツールです。._cfg0000_<name> ファイルは Portage が CONFIG_PROTECT 変数でプロテクトされているディレクトリーのファイルを上書きしたい時に生成されます。

dispatch-conf を使うと、ユーザーはすべての変更を追跡しつつ設定ファイルへの更新をマージできます。dispatch-conf は設定ファイル間の差分をパッチとして、または RCS リビジョン管理システムを使用して保管します。これはつまり、誰かが設定ファイルの更新中にミスをしたとしても、管理者はいつでもそのファイルを以前のバージョンに差し戻せるということです。

dispatch-conf を使用すると、ユーザーは設定ファイルをそのままにしておくか、新しい設定ファイルを使うか、現在のものを編集するか、または変更箇所を対話的にマージするか尋ねられます。また、dispatch-conf にはいくつかの素晴らしい追加機能もあります:

コメントの更新のみを含む設定ファイルの更新を自動的にマージする。
スペースの数のみが異なる設定ファイルを自動的にマージする。

まず /etc/dispatch-conf.conf を編集してから archive-dir 変数で参照されているディレクトリーを作成します。それから dispatch-conf を実行します:

root #dispatch-conf

dispatch-conf を実行すると、変更された各設定ファイルが一つずつ検討されます。現在の設定ファイルを新しいもので更新(置き換え)して次のファイルに進むには u を押します。新しい設定ファイルを消去(削除)して次のファイルに進むには z を押します。n キーは dispatch-conf に次のファイルにスキップするよう指示します。これを使ってマージを未来に延期することもできます。すべての設定ファイルが済むと dispatch-conf は終了します。同様に、いつでも q でアプリケーションを終了させることができます。

詳細については dispatch-conf の man ページを調べてください。現在の設定ファイルと新しい設定ファイルを対話的にマージしたり、新しい設定ファイルを編集したり、ファイル間の差分を検査する方法などが説明されています。

user $man dispatch-conf

etc-update

設定ファイルをマージするためのもう一つのツールが etc-update です。dispatch-conf と同様に対話的な設定マージ機能を提供し、些細な変更を自動マージすることもできます。

重要
etc-update はより古く、大部分が維持されていないユーティリティであることに注意すべきです。使い方は dispatch-conf ほどシンプルではなく機能も豊富ではありません。設定ファイルの旧バージョンはバックアップされないことに注意してください。ひとたびファイルが更新されれば古いバージョンは永久に失われます。

可能な場合は dispatch-conf を使用することが強く推奨されます (etc-update ではなく前の節を参照してください)。

root #etc-update

直接的な変更をマージした後に、プロテクトされている更新待ちファイルの一覧が提供されます。その下に選択可能なオプションが表示されます:

コード etc-update で提供されるオプション

Please select a file to edit by entering the corresponding number.
              (-1 to exit) (-3 to auto merge all remaining files)
                           (-5 to auto-merge AND not use 'mv -i'):

-1 を入力すると etc-update は終了しそれ以上の変更は行われません。-3 や -5 ではリストされた設定ファイルがすべて新しいバージョンで上書きされます。ですから、まず最初に自動的に更新されるべきでない設定ファイルを選択することが大事です。これは設定ファイルの左に表示されている番号を単に入力するだけです。

例として、/etc/pear.conf を選択してみます:

コード 特定の設定ファイルを更新する

Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
[...]
End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
1) Replace original with update
2) Delete update, keeping original as is
3) Interactively merge original with update
4) Show differences again

2つのファイルの差異が表示されます。更新された設定ファイルが問題なく使えるなら 1 を入力してください。更新された設定ファイルが不要、または新しかったり有用であったりする情報を何も提供していない場合には 2 を入力してください。現在の設定ファイルを対話的に更新する必要がある場合には 3 を入力してください。

対話的マージについてはここでさらに詳述しても意味はありません。完全を期するために、ここでは2つのファイルをマージする間に利用できるコマンドの候補を挙げます。ユーザーには2つの文章(元々のものと新しく提案されているもの)と、以下のコマンドの中の1つを入力できるプロンプトが表示されます:

コード 対話的マージで利用可能なコマンド

ed:     Edit then use both versions, each decorated with a header.
eb:     Edit then use both versions.
el:     Edit then use the left version.
er:     Edit then use the right version.
e:      Edit a new version.
l:      Use the left version.
r:      Use the right version.
s:      Silently include common lines.
v:      Verbosely include common lines.
q:      Quit.

重要な設定ファイルの更新を終えたら、他のすべての設定ファイルを自動的に更新することができます。それ以上更新できる設定ファイルがなくなると etc-update は終了します。

quickpkg

quickpkg を使うと、既にシステムにマージされたパッケージのアーカイブを作ることができます。それらのアーカイブはビルド済みパッケージとして利用できます。quickpkg の実行は簡単です: アーカイブするパッケージの名前を付け加えるだけです。

たとえば curl、orage、そして procps をアーカイブするには:

root #quickpkg curl orage procps

ビルド済みパッケージは $PKGDIR (デフォルトでは /var/cache/binpkgs/) に保管されます。これらのパッケージは $PKGDIR/CATEGORY に配置されています。

← ソフトウェアのブランチを併用する Home カスタムパッケージリポジトリ →

Gentoo リポジトリのサブセットを使用する

パッケージやカテゴリを除外する

あるカテゴリ/パッケージを選択的にアップデートし、他のカテゴリ/パッケージを無視することができます。これは emerge --sync ステップの間に rsync にカテゴリ/パッケージを除外させることによって達成できます。

警告
この方法を動作させるためには、マニフェスト検証を無効化する必要があります。これはリポジトリのセキュリティを低下させるでしょう。検証を無効化するには、sys-apps/portage パッケージの rsync-verify USE フラグを無効化するか、Gentoo ebuild リポジトリの repos.conf エントリで sync-rsync-verify-metamanifest=no (man 5 portage を参照) を設定してください。

除外パターンを含むファイルの名前を /etc/portage/make.conf の PORTAGE_RSYNC_EXTRA_OPTS 変数で定義します:

ファイル /etc/portage/make.conf除外ファイルを定義する

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

ファイル /etc/portage/rsync_excludesすべてのゲームを除外する

games-*/*

警告
ebuild リポジトリの一部を除外することは、特に Gentoo ebuild リポジトリに関しては、依存関係の問題につながることがあります! 新しい許可されたパッケージは、新しい除外されたパッケージに依存していることがあります。除外はサポート対象外ですので、このリスクを念頭に入れた上で進めてください。

非公式の ebuild を追加する

カスタム ebuild リポジトリを作成する

手動作成

Gentoo ebuild リポジトリを通じて公式に利用可能でない ebuild を、Portage に使用させることができます。このためには、サードパーティーの ebuild を格納する新しいディレクトリ(たとえば /var/db/repos/localrepo)を作成してください。この新しいリポジトリは Gentoo の公式リポジトリと同じディレクトリ構造である必要があります。

root #

mkdir -p /var/db/repos/localrepo/{metadata,profiles}

root #

chown -R portage:portage /var/db/repos/localrepo

次に、リポジトリ用に実用的な名前を選びましょう。次の例では "localrepo" を名前に使っています:

root #echo 'localrepo' > /var/db/repos/localrepo/profiles/repo_name

Portage に、リポジトリマスターが Gentoo のメイン ebuild リポジトリであること、(このリポジトリはrsync サーバー、git ミラー、あるいはその他のリポジトリの種類などの、外部のソースで裏付けられているわけではないので)ローカルリポジトリを自動的に同期しないことを通知します:

ファイル /var/db/repos/localrepo/metadata/layout.conf

masters = gentoo
auto-sync = false
thin-manifests = true
sign-manifests = false

最後に、/etc/portage/repos.conf の中にリポジトリ設定ファイルを作成してローカルシステムのリポジトリを有効にします。このファイルは Portage にカスタムローカルリポジトリが見つけられる場所を通知します:

ファイル /etc/portage/repos.conf/localrepo.conf

[localrepo]
location = /var/db/repos/localrepo

省略可能: eselect repository を使ってリポジトリを作成する

別の方法として、カスタム ebuild リポジトリは eselect repository モジュール (app-eselect/eselect-repository に含まれます) を使用してすぐに作成することができます。次の例で、localrepo は選択した名前に置き換えてください:

root #eselect repository create localrepo

Adding localrepo to /etc/portage/repos.conf/eselect-repo.conf ...
Repository <ebuild_repository_name> created and added

"localrepo" という名前の空のリポジトリが /var/db/repos/localrepo で利用可能になるでしょう。

複数のリポジトリを扱う

複数の ebuild リポジトリを開発したり、Gentoo リポジトリに送る前にパッケージをテストしたり、あるいはさまざまなソースからの非公式 ebuild を使用したい人のために、app-eselect/eselect-repository パッケージはリポジトリを最新の状態に保つのを助けるツールも提供しています。eselect repository の記事も参照してください。

eselect repository を使ってリポジトリを追加する

たとえば、GURU リポジトリを有効にするには:

root #eselect repository enable guru

この方法で追加されたリポジトリの更新は、同期のたびに自動で行われるでしょう:

root #emerge --sync

Portage で管理されていないソフトウェア

Portage を自分で管理しているソフトウェアと共に使用する

時々、Portage でソフトウェアタイトルを提供できるにも関わらず、Portage にプロセスを自動化させることなくソフトウェアを個別に設定、インストール、メンテナンスしたい場合があります。既知の例はカーネルソースや Nvidia ドライバーなどのパッケージです。Portage に特定のパッケージがシステムに手動でインストールされていることを知らせる(したがって、依存関係の計算の際にこの情報が考慮される)よう設定できます。このプロセスは injecting と呼ばれており、/etc/portage/profile/package.provided ファイルを通じて Portage によりサポートされています。

たとえば、手動でインストールされた gentoo-sources-4.9.16 について Portage に知らせるには以下の行を /etc/portage/profile/package.provided に追加します:

ファイル /etc/portage/profile/package.providedgentoo-sources-4.9.16 を手動でインストール済みとしてマークする

sys-kernel/gentoo-sources-4.9.16

メモ
このファイルはバージョンを = 演算子なしで使用します。

← 追加ツール Home 高度な機能 →

はじめに

多くの読者にとって、これまでに受け取った情報は Linux のすべての操作をするのに十分です。しかし、Portage にはより多くのことができます; その機能の多くは高度なカスタマイズのためのものであるか、またはあまり一般的でない特定のケースにのみ適用できるものです。

もちろん、高い柔軟性により、膨大な数の潜在的な状況がありえます。それらすべてをここに文書化することは不可能でしょう。代わりに、特定のニッチに合わせて補足できるよう、いくつかの一般的な問題に焦点を当てることをゴールとします。こうした微調整や豆知識は Gentoo wiki のあちこちで他にも見つけることができます。

これらの追加的機能の全てではないとしても大部分は、Portage とともに提供されるマニュアルページを探ることで簡単に見つけることができます。

user $

man portage

user $

man make.conf

最後に、これらは高度な機能であり、正しく設定されていないとデバッグやトラブルシューティングがずっと難しくなるかもしれない、ということを知っておいてください。バグ報告を作成する際には、これらのカスタマイズについて明示的に言及することを忘れないようにしてください。

パッケージごとの環境変数

/etc/portage/env を使用する

デフォルトでは、パッケージのビルドでは CFLAGS、MAKEOPTS その他の /etc/portage/make.conf で定義されている環境変数を使用します。場合によっては特定のパッケージに対して異なる変数を提供することが有益です。そうするために、Portage は /etc/portage/env ディレクトリと /etc/portage/package.env ファイルの使用をサポートしています。

/etc/portage/package.env ファイルは、環境変数の変更が必要なパッケージと、どの識別子ファイルを適用するか Portage に示すための特定の識別子のリストを含んでいます。識別子の名前は自由書式です。Portage は大文字小文字を区別して識別子とまったく同じ名前のファイルを探します。さらなる詳細については次の例を参照してください。

例: 特定のパッケージでデバッグを使用する

例として、media-video/mplayer パッケージでデバッグを有効化します。

/etc/portage/env/debug-cflags というファイルでデバッグ用の変数をセットします。ファイル名は任意に選択できますが、もちろん、後でそのファイルが存在する理由を確認するときに明確にわかるように、ファイルの目的を反映させましょう。/etc/portage/env ディレクトリがまだ存在しない場合はそれを作成する必要があるでしょう:

root #mkdir /etc/portage/env

ファイル /etc/portage/env/debug-cflagsデバッグのために特定の変数を設定する

# デバッグのために CFLAGS に -ggdb を追加する
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

次に、package.env ファイル内の新しいデバッグ識別子を使用するように、media-video/mplayer パッケージにタグ付けします:

ファイル /etc/portage/package.envmplayer パッケージで debug-cflags 識別子を使用する

media-video/mplayer debug-cflags

emerge のプロセスにフックする

/etc/portage/bashrc と関連ファイルを使用する

Portage が ebuild を扱う場合には、bash 環境を使用してその内部でさまざまなビルド関数 (src_prepare、src_configure、pkg_postinst など) を呼びます。Portage ではシステム管理者が特定の bash 環境を設定することができます。

特定の bash 環境を使用する利点は、emerge で行われる各段階において emerge のプロセスにフックできることです。これはすべての emergeに対して(/etc/portage/bashrc を通して)、またはパッケージごとの環境を使用して(前に説明したように /etc/portage/env を通して)行うことができます。

プロセスにフックするために、bash 環境では ebuild 開発の際に常に利用可能な(P、PF などのような)変数と同様に、EBUILD_PHASE、CATEGORY 変数も取り上げることができます。これらの変数の値をもとに、追加の段階や関数を実行できます。

例: ファイルデータベースを更新する

この例では、/etc/portage/bashrc ファイルを使用していくつかのファイルデータベースアプリケーションを実行し、データベースがそのシステムで最新の状態になるようにします。この例で使用されているアプリケーションは aide (an intrusion detection tool) と(mlocate と共に使用される) updatedb ですが、これらは例として意図されています。これをAIDEのためのガイドとは考えないでください。

この場合に /etc/portage/bashrc を使用するには、postrm (ファイルの削除後)と postinst (ファイルのインストール後)をフックする必要があります。なぜなら、これらがファイルシステム上のファイルが変更された時点だからです。

ファイル /etc/portage/bashrcpostinst および postrm フェーズにフックする

if [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ];
then
  echo ":: Calling aide --update to update its database"
  aide --update
  echo ":: Calling updatedb to update its database"
  updatedb
fi

ebuild リポジトリ同期の後にタスクを実行する

ロケーション /etc/portage/postsync.d を使用する

ebuild の各フェーズへのフックに加えて、Portage はフック機能のためのもう一つの選択肢を提供します: postsync.d です。これらの種類のフックは Gentoo ebuild リポジトリの更新 (同期ともいいます) の後に実行されます。Gentoo リポジトリの更新後にタスクを実行するには、スクリプトを /etc/portage/postsync.d ディレクトリの中に置いてください。ディレクトリ内のすべてのファイルが実行可能としてマークされていることを確認してください、そうでないと実行されません。

例: eix-update を実行する

eix-sync をリポジトリの同期に使用していない場合でも、eix-update という名前の /usr/bin/eix へのシンボリックリンクを /etc/portage/postsync.d に置くことで、eix データベースを emerge --sync (または emerge-webrsync)の後に更新することができます。

root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update

メモ
異なる名前を選択した場合は代わりに /usr/bin/eix-update を実行するスクリプトにしなければなりません。eix バイナリーは、どの関数を実行するか判断するために自身がどのように呼び出されたのかを検査します。eix を指すにもかかわらず eix-update という名前でないシンボリックリンクが作成された場合、正しく動作しません。

profile の設定を上書きする

/etc/portage/profile を使用する

デフォルトでは、Gentoo は /etc/portage/make.profile (ターゲットプロファイルのディレクトリへのシンボリックリンク) ターゲットプロファイルのディレクトリへのシンボリックリンクが指すプロファイルに含まれている設定を使用します。これらのプロファイルは、(parent ファイルを通して) 他のプロファイルから継承した設定と独自の設定両方を定義しています。

/etc/portage/profile を使用することで、システム管理者はパッケージ (どのパッケージが system セットの一部として扱われるか)、強制される USE フラグなどのプロファイル設定を上書きすることができます。

例: nfs-utils を system セットに追加する

NFS ベースのファイルシステムを重要なファイルシステムに使用する場合、net-fs/nfs-utils をシステムパッケージとしてマークし、管理者がこれを unmerge しようと試みた際には Portage が厳重に警告を出すようにする必要があるでしょう。

これを実現するには、パッケージの先頭に * (アスタリスク記号) を付けて /etc/portage/profile/packages ファイルに追加する必要があります:

ファイル /etc/portage/profile/packagesnet-fs/nfs-utils をシステムパッケージとしてマークする

*net-fs/nfs-utils

非標準のパッチを適用する

eapply_user を使用する

いくつかの ebuild を同様に管理するために、ebuild の開発者はよく使われる関数を定義した eclass (これらはシェルライブラリーです)を使用します。これらの eclass の一つが epatch_user と呼ばれる便利な関数を提供する epatch.eclass です。

eapply_user 関数は、/etc/portage/patches/<category>/<package>[-<version>[-<revision>]] の最初に見つかったディレクトリーにあるソースコードパッチを適用します。

レガシーな (EAPI 6 以前の) ebuild では幸運なことに、ユーザーはこの章で先に提供した情報を使って、例えば prepare フェーズにフックすることでこの関数を呼ぶことができます。この関数は必要な回数だけ呼ぶことができます - 関数はパッチを一回だけ適用します。

例: Firefox にパッチを適用する

www-client/firefox パッケージは既に ebuild 内で eapply_user を呼んでいる (暗黙的にかもしれません) 多くのパッケージの一つなので、特に何かを上書きする必要はありません。

何らかの理由(たとえば、開発者がパッチを提供し、報告されたバグがこれによって解決されるか確認するよう頼まれた場合)で Firefox をパッチしたい場合、必要なのはパッチを /etc/portage/patches/www-client/firefox(パッチが後のバージョンに干渉しないように、フルネームとバージョンを使用した方がおそらくよいでしょう) に置き、Firefox を再度ビルドすることだけです。

← カスタムパッケージリポジトリ Home はじめに →

Warning: Display title "Gentoo Linux ppc ハンドブック:Portage での作業" overrides earlier display title "ハンドブック:PPC/フル/Portage".