Handbook:Parts/Portage/Advanced/ja

はじめに
多くのユーザーにとって、これまでに受け取った情報は Linux のすべての操作をするのに十分です. しかし、Portage にはより多くのことができます; その機能の多くは上級ユーザー向けであるか、またはあまり一般的でない特定のケースにのみ適用できるものです. それでも、このことはこれらの機能を文書化しない理由にはなりません.

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

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

最後に、これらは高度な機能であり、正しく動かない場合にデバッグやトラブルシューティングがとても難しくなるかもしれない、ということを知っておいてください. バグに遭遇してバグ報告を作成する際には、これらに言及することを忘れないようにしてください.

/etc/portage/env を使用する
デフォルトでは、パッケージのビルドでは CFLAGS 、 MAKEOPTS その他の で定義されている環境変数を使用します. しかしながら、ある場合には特定のパッケージに対して異なる変数を提供することが有益かもしれません. そうするために、Portage は と  の使用をサポートしています.

ファイルは環境変数の変更が必要なパッケージと Portage にどの変更をすべきか知らせるための特定の識別子のリストを含んでいます. 識別子の名前は自由書式で、Portage は変数を ファイルから探します.

例: 特定のパッケージでデバッグを使用する
As an example, we enable debugging for the package.

First of all, set the debugging variables in a file called. The name is arbitrarily chosen, but of course reflects the reason of the deviation to make it more obvious later why a deviation was put in.

Next, we tag the package to use this content:

Using /etc/portage/bashrc and affiliated files
When Portage works with ebuilds, it uses a bash environment in which it calls the various build functions (like,  ,  , etc.). But Portage also allows users to set up a specific bash environment.

The advantage of using a specific bash environment is that it allows users to hook in the emerge process during each step it performs. This can be done for every emerge (through ) or by using per-package environments (through as discussed earlier).

To hook in the process, the bash environment can listen to the variables EBUILD_PHASE, CATEGORY as well as the variables that are always available during ebuild development (such as P , PF , ...). Based on the values of these variables, additional steps/functions can then be executed.

Example: Updating the file database
In this example, we'll use to call some file database applications to ensure their databases are up to date with the system. The applications used in the example are (an intrusion detection tool) and  (to use with ), but these are meant as examples. Do not consider this as a guide for AIDE ;-)

To use for this case, we need to "hook" in the   (after removal of files) and   (after installation of files) functions, because that is when the files on the file system have been changed.

Using /etc/portage/postsync.d location
Until now we've talked about hooking into the ebuild processes. However, Portage also has another important function: updating the Gentoo repository. In order to run tasks after updating the Gentoo repository, put a script inside and make sure it is marked as executable.

Example: Running eix-update
If was not used to update the tree, then it is still possible to update the eix database after running  (or ) by putting a symlink to  called  in.

Using /etc/portage/profile
By default, Gentoo uses the settings contained in the profile pointed to by (a symbolic link to the right profile directory). These profiles define both specific settings as well as inherit settings from other profiles (through their parent file).

By using, users can override profile settings such as packages (what packages are considered to be part of the system set), forced use flags and more.

Example: Adding nfs-utils to the system set
When using an NFS-based file systems for rather critical file systems, it might be necessary to mark as a system package, causing Portage to heavily warn administrators if they would attempt to unmerge it.

To accomplish that, we add the package to, prepended with a :

Using epatch_user
To manage several ebuilds in a similar manner, ebuild developers use eclasses (which are shell libraries) that define commonly used functions. One of these eclasses is which offers a helpful function called.

The  function applies source code patches that are found in, whatever directory is found first. Sadly, not all ebuilds automatically call this function so just putting a patch in this location might not always work.

Luckily, with the information provided earlier in this chapter, users can call this function by hooking into, for instance, the prepare phase. The function can be called as many times as necessary - it will only apply the patches once.

Example: Applying patches to Firefox
The package is one of the many that already call   from within the ebuild, so there is no need to override anything specific.

If for some reason (for instance because a developer provided a patch and asked to check if it fixes the bug reported) patching Firefox is wanted, all that is needed is to put the patch in (probably best to use the full name and version so that the patch does not interfere with later versions) and rebuild Firefox.