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 の値は現在の nice 値に加算されます。

nice 値についての詳細は、nice の man page を見てください:

user $man nice

出力の動作

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

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

1つのブランチを使う

stable

ACCEPT_KEYWORDS 変数がシステムでどのブランチを使うか定義しています。デフォルトは、たとえば ppc などの、そのシステムのアーキテクチャ用の stable ソフトウェアブランチです。

stable ブランチを使い続けることをお勧めします。しかしながら、管理者が不安定なソフトウェアを実行することで Gentoo プロジェクトを支援したい場合には、アーキテクチャの testing ブランチを使用することもできます。この場合は ~ppc です。不安定なソフトウェアを実行して問題に直面した場合、https://bugs.gentoo.org にバグレポートを送信する必要があるかもしれないことにご注意ください。

testing

より最近のソフトウェアを使うためには、ユーザーは代わりに testing ブランチの使用を検討できます。Portage に testing ブランチを使用させるには、アーキテクチャの前に ~ を加えます。

testing ブランチはまさにその名の通りのものです - テスト中なのです。パッケージが testing ブランチにある場合、それは開発者がそのパッケージは機能すると感じているけれども未だ徹底的にはテストされていないということを意味します。testing ブランチを使用しているユーザーはパッケージのバグを初めて発見する人になる可能性があり、そのような場合には開発者にそのバグについて知らせるためにバグ報告を送信するべきです。

ただし気を付けてください; testing ブランチの使用は、安定性に関する問題、不完全なパッケージ処理(たとえば依存関係の誤り/不足)、あまりに頻繁な更新(多量のビルドにつながる)、または壊れたパッケージといったものを招くかもしれません。Gentoo の仕組みや問題の解決方法を知らないユーザーはテスト済みの stable ブランチを使い続けることをお勧めします。

たとえば ppc アーキテクチャの testing ブランチを選択するには、/etc/portage/make.conf を編集して以下のようにセットします:

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

ACCEPT_KEYWORDS="~ppc"

stable から testing に変更する時には、ユーザーは大量のパッケージが更新されることに気が付くでしょう。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 ブランチの特定のソフトウェアバージョンをテストに使用する一方でその後のバージョンについては Portage に testing ブランチを使用してほしくない場合、そのバージョンを package.accept_keywords の場所に追加してください。この場合は = 演算子を使用します。<= 、 < 、 > あるいは >= 演算子を使ってバージョンの範囲を入力することもできます。

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

以下の例では、たとえ testing ブランチであったとしても gnumeric-1.2.13 のインストールを Portage で許可しています:

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

=app-office/gnumeric-1.2.13

マスクされたパッケージ

package.unmask

重要
Gentoo 開発者は、パッケージのアンマスクの使用をサポートしません。これを行う時には十分注意を払ってください。package.unmask や package.mask に関するサポートリクエストには回答がされないかもしれません。

パッケージが Gentoo 開発者によってマスクされており、 package.mask ファイル(デフォルトでは /var/db/repos/gentoo/profiles/ にあります)に書かれている理由にも関わらずユーザーがそれでもこのパッケージを使用したい場合、使いたいバージョン(通常はプロファイルの package.mask ファイルとまったく同じ1行)を /etc/portage/package.unmask ファイル(またはこれがディレクトリになっている場合はその中のファイル)に追加してください。

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

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

=net-mail/hotwayd-0.8

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

package.mask

Portage に、一定のパッケージや、あるパッケージの特定のバージョンを考慮しないようにさせることができます。そうするには、適切な1行を /etc/portage/package.mask の場所(そのファイル、またはそのディレクトリの中のファイルのどちらか)に追加してパッケージをマスクします。

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

ファイル /etc/portage/package.mask4.9.16 よりも新しいバージョンの 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 ほどシンプルではなく機能も豊富ではありませんが、対話的な設定マージ機能は提供されていますし、些細な変更を自動マージすることもできます。

しかしながら、dispatch-conf とは異なり、etc-update は設定ファイルの旧バージョンを保持しません。ひとたびファイルが更新されれば古いバージョンは永久に失われます。気を付けてください、古い設定ファイルを維持する場合には etc-update を使用している時の方が dispatch-conf を使用するよりもかなり安全性が低くなります。

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 にカテゴリ/パッケージを除外させることによって達成できます。

除外パターンを含むファイルの名前を /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-*/*

ただし、これは依存関係の問題につながるかもしれないことに注意してください。新しい許可されたパッケージが、新しい除外されたパッケージに依存しているかもしれないためです。

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

非公式の 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

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

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

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

複数のオーバーレイを扱う

複数のオーバーレイで開発を行ったり、Gentoo リポジトリに送る前にパッケージをテストしたり、あるいは単にさまざまなソースからの非公式 ebuild を使用したいパワーユーザーのために、app-portage/layman パッケージが layman を提供しています。これはユーザーがオーバーレイリポジトリを最新の状態に保つのを補助するツールです。

代わりに、app-eselect/eselect-repository をインストールして Portage が備えている同期機能を利用することもできます。Eselect/Repository も参照してください。

eselect-repository

リポジトリの追加は、eselect モジュール (app-eselect/eselect-repository で入手可能) を使うと簡単に行えます:

たとえば、hardened-development オーバーレイを有効にするには:

root #eselect repository enable hardened-development

この方法で追加されたオーバーレイの更新は、

root #emerge --sync

をすることによって自動的に行われます。

Layman

最初に Overlays User Guide で示されているように layman のインストールと設定を行い、それからご希望のリポジトリを layman -a で追加します。

たとえば、hardened-development オーバーレイを有効にするには:

root #layman -a hardened-development

layman を通じていくつのリポジトリが使用されているかに関わらず、以下のコマンドでそれらすべてのリポジトリを更新できます:

root #layman -S

オーバーレイの取扱いについての詳細は man layman や、前にリンクした layman/overlay ユーザーガイドを読んでください。

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 は変数を /etc/portage/env/識別子ファイルから探します。

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

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

まずはじめに、/etc/portage/env/debug-cflags というファイルでデバッグ用の変数をセットします。名前は任意に選択できますが、もちろん、後でなぜ変更が加えられているのか明確にするために変更の理由を反映させましょう。

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

CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

次に、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

--sync の後にタスクを実行する

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

ここまで ebuild プロセスのフックについて話してきました。しかしながら、Portage はもう一つの重要な機能を備えています: Gentoo リポジトリの更新です。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/packagesnfs-utils をシステムパッケージとしてマークする

*net-fs/nfs-utils

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

epatch_user を使用する

メモ
epatch_user 関数は EAPI 5以下に適用できます。EAPI 6以上については eapply_user を参照してください。

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

epatch_user 関数は、/etc/portage/patches/<category>/<package>[-<version>[-<revision>]] の最初に見つかったディレクトリーにあるソースコードパッチを適用します。残念なことにすべての ebuild が自動的にこの関数を呼ぶわけではないので、パッチをこの場所に置くだけでは動作しない場合があるでしょう。

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

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

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

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

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

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