ハンドブック:PPC64/Portage/ブランチ
1 つのブランチを使う
stable
ACCEPT_KEYWORDS 変数はシステムのソフトウェアブランチを定義しています。この変数は /etc/portage/make.conf ファイル内で設定され、デフォルトでは stable ブランチに設定されます。この場合、デフォルト値は ppc64 です。
# 次の値はデフォルトで設定され、明示的に定義する必要は_ありません_。
ACCEPT_KEYWORDS="ppc64"
より簡単な体験のために、そして不安定化等の問題のリスクがより低いことから、ハンドブックとしては 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 another, 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 の値を ~ppc64 に設定してください。
# amd64 アーキテクチャに対して testing ブランチ (~) を使用するように、Portage に指示します。
ACCEPT_KEYWORDS="~ppc64"
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 ブランチを使用するには:
app-office/gnumeric
特定のバージョンをテストする
testing ブランチの特定のソフトウェアバージョンを使用する一方で、その後のバージョンについては testing ブランチからの更新を許可しないようにするために、パッケージの特定のバージョンを package.accept_keywords ファイル内で定義することができます。特定のバージョンを定義するには、=
演算子を活用できます。<=
、<
、>
あるいは >=
演算子を使って、バージョンの範囲を入力することもできます。
いかなる場合でも、パッケージバージョン情報を定義する際には演算子を使わなければなりません。バージョン情報がなければ演算子は使用できません。
以下の例では、gnumeric の特定のバージョン (バージョン 1.2.13) のインストールを、たとえそれが testing ブランチにある場合でも許可するように、Portage に指示しています:
=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 の場所に追加することでアンマスクできます:
=mail-client/mutt-2.2.9
/var/db/repos/gentoo/profiles/package.mask のエントリーにパッケージのバージョンの範囲が含まれている場合、実際に必要なバージョンのみをアンマスクする必要があります。演算子を使用してバージョンを指定する方法については前の節をお読みください。
package.mask
特定のパッケージをインストールしたり、あるパッケージを特定のバージョンへ更新したりしないように、Portage に指示することもできます。このことを、パッケージをマスクするといいます。パッケージをマスクするには、必要に応じた修飾子を /etc/portage/package.mask の場所 (そのファイル、またはそのディレクトリの中のファイルのどちらか) に追加してください。
たとえば Portage に gentoo-sources-6.6.21 よりも新しいカーネルソースをインストールさせないようにするには、package.mask の場所に以下の行を追加します:
>sys-kernel/gentoo-sources-6.6.21