This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Gentoo Linux alpha ハンドブック:Portage での作業
Portage におけるファイル
設定ディレクティブ
Portage comes with a default configuration stored in /usr/share/portage/config/make.globals. All Portage configuration is handled through variables. What variables portage listens to and what they mean are described later.
Since many configuration directives differ between architectures, Portage also has default configuration files which are part of the system profile. This profile is pointed to by the /etc/portage/make.profile symlink; Portage's configurations are set in the make.defaults files of the profile and all parent profiles. We'll explain more about profiles and the /etc/portage/make.profile directory later on.
When changing a configuration variable, do not alter /usr/share/portage/config/make.globals or make.defaults. Instead use /etc/portage/make.conf which has precedence over the previous files. For more information, read the /usr/share/portage/config/make.conf.example. As the name implies, this is merely an example file - Portage does not read in this file.
It is also possible to define a Portage configuration variable as an environment variable, but we don't recommend this.
profile 特有の情報
We've already encountered the /etc/portage/make.profile directory. Well, this is not exactly a directory but a symbolic link to a profile, by default one inside /usr/portage/profiles/ although one can create their own profiles elsewhere and point to them. The profile this symlink points to is the profile to which the system adheres.
A profile contains architecture-specific information for Portage, such as a list of packages that belong to the system corresponding with that profile, a list of packages that don't work (or are masked-out) for that profile, etc.
ユーザーによる設定
When Portage's behavior needs to be changed regarding the installation of software, then the right set of files inside /etc/portage/ will need to be changed. It is highly recommended to use files within /etc/portage/ and highly discouraged to override the behavior through environment variables!
Within /etc/portage/ users can create the following files:
- package.mask which lists the packages that Portage should never try to install
- package.unmask which lists the packages Portage should be able to install even though the Gentoo developers highly discourage users from emerging them
- package.accept_keywords which lists the packages Portage should be able to install even though the package hasn't been found suitable for the system or architecture (yet)
- package.use which lists the USE flags to use for certain packages without having the entire system use those USE flags
These don't have to be files; they can also be directories that contain one file per package. More information about the /etc/portage/ directory and a full list of possible files that can be created can be found in the Portage man page:
user $man portageChanging Portage file and directory locations
The previously mentioned configuration files cannot be stored elsewhere - Portage will always look for those configuration files at those exact locations. However, Portage uses many other locations for various purposes: build directory, source code storage, Gentoo repository location, ...
All these purposes have well-known default locations but can be altered to personal taste through /etc/portage/make.conf. The rest of this chapter explains what special-purpose locations Portage uses and how to alter their placement on the filesystem.
This document isn't meant to be used as a reference though. To get 100% coverage, please consult the Portage and make.conf man pages:
user $man portage
user $man make.conf保存されるファイル
Gentoo ebuild repository
The default location of the Gentoo ebuild repository is at /usr/portage. This is defined by the default repos.conf file found at /usr/share/portage/config/repos.conf. To modify the default, copy this file to /etc/portage/repos.conf/gentoo.conf and change the location setting. When storing the Gentoo ebuild repository elsewhere (by altering this variable), don't forget to change the /etc/portage/make.profile symbolic link accordingly.
After changing the location setting in /etc/portage/repos.conf/gentoo.conf, it is recommended to alter the following variables in /etc/portage/make.conf as well since they will not notice the location change. This is due to how Portage handles variables: PKGDIR, DISTDIR, and RPMDIR.
ビルド済バイナリ
Even though Portage doesn't use prebuilt binaries by default, it has extensive support for them. When asking Portage to work with prebuilt packages, it will look for them in /usr/portage/packages. This location is defined by the PKGDIR variable.
ソースコード
Application source code is stored in /usr/portage/distfiles by default. This location is defined by the DISTDIR variable.
Portage のデータベース
Portage stores the state of the system (what packages are installed, what files belong to which package, ...) in /var/db/pkg.
Do not alter these files manually! It might break Portage's knowledge of the system.
Portage のキャッシュ
The Portage cache (with modification times, virtuals, dependency tree information, ...) is stored in /var/cache/edb. This location really is a cache: users can clean it if they are not running any Portage-related application at that moment.
ソフトウェアをビルドするにあたり
Portage の一時ファイル
Portage's temporary files are stored in /var/tmp/ by default. This is defined by the PORTAGE_TMPDIR variable.
ビルド作業用ディレクトリ
Portage creates specific build directories for each package it emerges inside /var/tmp/portage/. This location is defined by the PORTAGE_TMPDIR variable with portage/ appended.
Live filesystem location
By default Portage installs all files on the current filesystem (/), but this can be changed by setting the ROOT environment variable. This is useful when creating new build images.
ログ記録機能
Ebuild logging
Portage can create per-ebuild log files, but only when the PORT_LOGDIR variable is set to a location that is writable by Portage (through the Portage user). By default this variable is unset. If PORT_LOGDIR is not set, then there will not be any build logs with the current logging system, though users may receive some logs from the new elog support.
If PORT_LOGDIR is not defined and elog is used, then build logs and any other logs saved by elog will be made available, as explained below.
Portage offers fine-grained control over logging through the use of elog:
- PORTAGE_ELOG_CLASSES: This is where users can define what kinds of messages to be logged. This can be any space-separated combination of info, warn, error, log, and qa.
- info: Logs "einfo" messages printed by an ebuild
- warn: Logs "ewarn" messages printed by an ebuild
- error: Logs "eerror" messages printed by an ebuild
- log: Logs the "elog" messages found in some ebuilds
- qa: Logs the "QA Notice" messages printed by an ebuild
- PORTAGE_ELOG_SYSTEM: This selects the module(s) to process the log messages. If left empty, logging is disabled. Any space-separated combination of save, custom, syslog, mail, save_summary, and mail_summary can be used. At least one module must be used in order to use elog.
- save: This saves one log per package in $PORT_LOGDIR/elog, or /var/log/portage/elog if $PORT_LOGDIR is not defined.
- custom: Passes all messages to a user-defined command in $PORTAGE_ELOG_COMMAND; this will be discussed later.
- syslog: Sends all messages to the installed system logger.
- mail: Passes all messages to a user-defined mailserver in $PORTAGE_ELOG_MAILURI; this will be discussed later. The mail features of elog require >=portage-2.1.1.
- save_summary: Similar to save, but it merges all messages in $PORT_LOGDIR/elog/summary.log, or /var/log/portage/elog/summary.log if $PORT_LOGDIR is not defined.
- mail_summary: Similar to mail, but it sends all messages in a single mail when emerge exits.
- PORTAGE_ELOG_COMMAND: This is only used when the custom module is enabled. Users can specify a command to process log messages. Note that the command can make use of two variables: ${PACKAGE} is the package name and version, while ${LOGFILE} is the absolute path to the logfile. For instance:
PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"
- PORTAGE_ELOG_MAILURI: This contains settings for the mail module such as address, user, password, mail server, and port number. The default setting is "root@localhost localhost". The following is an example for an SMTP server that requires username and password-based authentication on a particular port (the default is port 25):
PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"
- PORTAGE_ELOG_MAILFROM: Allows the user to set the "from" address of log mails; defaults to "Portage" if unset.
- PORTAGE_ELOG_MAILSUBJECT: Allows the user to create a subject line for log mails. Note that it can make use of two variables: ${PACKAGE} will display the package name and version, while ${HOST} is the fully qualified domain name of the host Portage is running on. For instance:
PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST} with some messages"
Users who used enotice with Portage-2.0.* must completely remove enotice, as it is incompatible with elog.
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 です。
1つのブランチを使う
stable
ACCEPT_KEYWORDS 変数がシステムでどのブランチを使うか定義しています。デフォルトは、たとえば alpha などの、そのシステムのアーキテクチャ用の stable ソフトウェアブランチです。
stable ブランチを使い続けることをお勧めします。しかしながら、安定性がさほど重要でない場合や管理者がバグ報告を https://bugs.gentoo.org に送って Gentoo を支援したい場合には、代わりに testing ブランチを使用することもできます。
testing
より最近のソフトウェアを使うためには、ユーザーは代わりに testing ブランチの使用を検討できます。Portage に testing ブランチを使用させるには、アーキテクチャの前に ~ を加えます。
testing ブランチはまさにその名の通りのものです - テスト中なのです。パッケージが testing ブランチにある場合、それは開発者がそのパッケージは機能すると感じているけれども未だ徹底的にはテストされていないということを意味します。testing ブランチを使用しているユーザーはパッケージのバグを初めて発見する人になる可能性があり、そのような場合には開発者にそのバグについて知らせるためにバグ報告を送信するべきです。
ただし気を付けてください; testing ブランチの使用は、安定性に関する問題、不完全なパッケージ処理(たとえば依存関係の誤り/不足)、あまりに頻繁な更新(多量のビルドにつながる)、または壊れたパッケージといったものを招くかもしれません。Gentoo の仕組みや問題の解決方法を知らないユーザーはテスト済みの stable ブランチを使い続けることをお勧めします。
たとえば alpha アーキテクチャの testing ブランチを選択するには、/etc/portage/make.conf を編集して以下のようにセットします:
/etc/portage/make.conftesting ブランチを使用するACCEPT_KEYWORDS="~alpha"
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 ファイル(デフォルトでは /usr/portage/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
/usr/portage/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
dispatch-conf
dispatch-conf is a tool that aids in merging the ._cfg0000_<name> files. ._cfg0000_<name> files are generated by Portage when it wants to overwrite a file in a directory protected by the CONFIG_PROTECT variable.
With dispatch-conf, users are able to merge updates to their configuration files while keeping track of all changes. dispatch-conf stores the differences between the configuration files as patches or by using the RCS revision system. This means that if someone makes a mistake when updating a config file, the administrator can revert the file to the previous version at any time.
When using dispatch-conf, users can ask to keep the configuration file as-is, use the new configuration file, edit the current one or merge the changes interactively. dispatch-conf also has some nice additional features:
- Automatically merge configuration file updates that only contain updates to comments.
- Automatically merge configuration files which only differ in the amount of whitespace.
Edit /etc/dispatch-conf.conf first and create the directory referenced by the archive-dir variable. Then, execute dispatch-conf:
root #dispatch-confWhen running dispatch-conf, each changed config file will be reviewed one at a time. Press u to update (replace) the current config file with the new one and continue to the next file. Press z to zap (delete) the new config file and continue to the next file. The n key will instruct dispatch-conf to skip to the next file. This can be done to delay a merge until a future time. Once all config files have been taken care of, dispatch-conf will exit. At any time, q can be used to exit the application as well.
For more information, check out the dispatch-conf man page. It describes how to interactively merge current and new config files, edit new config files, examine differences between files, and more.
user $man dispatch-confetc-update
Another tool to merge configuration files is etc-update. It is not as simple to use as dispatch-conf, nor as fully featured, but it does provide an interactive merging setup and can also auto-merge trivial changes.
However, unlike dispatch-conf, etc-update does not preserve the old versions of the config files. Once a file is updated, the old version is gone forever. Be very careful, as using etc-update is significantly less safe than using dispatch-conf when desiring to keep old configuration files.
root #etc-updateAfter merging the straightforward changes, a list of protected files will be provided that have an update waiting. At the bottom the possible options are shown:
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'):When entering -1, etc-update will exit and discontinue any other changes. With -3 or -5, all listed configuration files will be overwritten with the newer versions. It is therefore very important to first select the configuration files that should not be automatically updated. This is simply a matter of entering the number listed to the left of that configuration file.
As an example, we select the configuration file /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
The differences between the two files are shown. If the updated configuration file can be used without problems, enter 1. If the updated configuration file isn't necessary, or doesn't provide any new or useful information, enter 2. If the current configuration file has to be interactively updated, enter 3.
There is no point in further elaborating the interactive merging here. For completeness sake, we will list the possible commands that can be used while interactively merging the two files. Users are greeted with two lines (the original one, and the proposed new one) and a prompt at which the user can enter one of the following commands:
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.
After having finished updating the important configuration files, users can then automatically update all the other configuration files. etc-update will exit if it doesn't find any more updateable configuration files.
quickpkg
With quickpkg users can create archives of the packages that are already merged on the system. These archives can be used as prebuilt packages. Running quickpkg is straightforward: just add the names of the packages to archive.
For instance, to archive curl, orage, and procps:
root #quickpkg curl orage procpsThe prebuilt packages will be stored in $PKGDIR (/usr/portage/packages/ by default). These packages are placed in $PKGDIR/CATEGORY.
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-*/*
ただし、これは依存関係の問題につながるかもしれないことに注意してください。新しい許可されたパッケージが、新しい除外されたパッケージに依存しているかもしれないためです。
非公式の ebuild を追加する
カスタムリポジトリを定義する
Gentoo リポジトリを通じて公式に利用可能でない ebuild を Portage に使用させることができます。サードパーティーの ebuild を格納する新しいディレクトリ(たとえば /usr/local/portage)を作成します。Gentoo の公式リポジトリと同じディレクトリ構造を使用してください！
root #mkdir -p /usr/local/portage/{metadata,profiles}
root #chown -R portage:portage /usr/local/portage次に、リポジトリ用に実用的な名前を選びましょう。次の例では "localrepo" を名前に使っています:
root #echo 'localrepo' > /usr/local/portage/profiles/repo_namePortage に、リポジトリマスターが Gentoo のメインリポジトリであること、(このリポジトリはrsync サーバー、git ミラー、あるいはその他のリポジトリソースで裏付けられているわけではないので)リポジトリを自動的に同期しないことを通知します:
/usr/local/portage/metadata/layout.confmasters = gentoo auto-sync = false
最後に、/etc/portage/repos.conf の中にリポジトリ設定ファイルを作成してローカルシステムのリポジトリを有効にします。このファイルは Portage にローカルリポジトリが見つけられる場所を通知します:
/etc/portage/repos.conf/localrepo.conf[localrepo] location = /usr/local/portage
複数のオーバーレイを扱う
複数のオーバーレイで開発を行ったり、Gentoo リポジトリに送る前にパッケージをテストしたり、あるいは単にさまざまなソースからの非公式 ebuild を使用したいパワーユーザーのために、app-portage/layman パッケージが layman を提供しています。これはユーザーがオーバーレイリポジトリを最新の状態に保つのを補助するツールです。
代わりに、app-eselect/eselect-repository をインストールして Portage が備えている同期機能を利用することもできます。Eselect/Repository も参照してください。
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-developmentlayman を通じていくつのリポジトリが使用されているかに関わらず、以下のコマンドでそれらすべてのリポジトリを更新できます:
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
このファイルはバージョンを
= 演算子なしで使用します。
はじめに
多くのユーザーにとって、これまでに受け取った情報は 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 と呼ばれる便利な関数を提供する eutils.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 を再度ビルドすることだけです。
Warning: Display title "Gentoo Linux alpha ハンドブック:Portage での作業" overrides earlier display title "ハンドブック:Alpha/フル/Portage".