Binary package guide/ja

Portage は、通常の ebuild のほかに、バイナリーパッケージの作成とインストールにも対応しています. このガイドでは、バイナリーパッケージの作成方法、インストール方法、バイナリーパッケージサーバーのセットアップ方法について説明します.

はじめに
There are many reasons why some system administrators like using binary packages for software installations on Gentoo:


 * 1) It allows administrators to save time when keeping similar systems updated. Having to compile everything from source can become time consuming. Maintaining several similar systems, possibly some of them with older hardware, can be much easier if only one system has to compile everything from source and the other systems use the binary packages.
 * 2) Do safe updates. For mission-critical systems in production it is important to stay usable as much as possible. This can be done by a staging server that performs all updates first to itself. Once the staging server is in a good state the updates can then be applied to the critical systems. A variant of this approach is to do the updates in a chroot on the same system and use the binaries created there on the real system.
 * 3) As a backup. Often binary packages are the only way of recovering a broken system (i.e. broken compiler). Having pre-compiled binaries around either on a binary package server or locally can be of great help in case of a broken toolchain.
 * 4) It aids in updating very old systems. The task of updating very old systems can be greatly eased using binary packages. It is usually helpful to install binary packages on old systems because they do not require build time dependencies to be installed/updated. Binaries packages also avoid failures in build processes since they are pre-compiled.

このガイドでは、次のトピックに焦点を当てます. :


 * Creating binary packages.
 * Distributing the packages to clients.
 * Implementing binary packages.
 * Maintaining the binary packages.

最後に、バイナリパッケージの扱い方に関するいくつかの高度な話題を扱います.

バイナリパッケージを作成する
バイナリパッケージを作成する主な方法は3つあります：


 * 1) After a regular installation, using the  application.
 * 2) Explicitly during an  operation by using the    option.
 * 3) Automatically through the use of the   value in Portage's FEATURES variable.

これらの三つの方法のうちいずれをとっても PKGDIR 変数よって指定されるディレクトリにバイナリパッケージが作成されます. (デフォルトではです)

quickpkg を利用する
は一つ以上のdependency atom (あるいはパッケージセット)を取り、そのatomと一致するインストールされたパッケージに対するバイナリパッケージを作成します.

例えば、すべてのインストールされたGCCのバージョンのバイナリパッケージを作るには

システム上のインストールされたすべてのパッケージに対してバイナリパッケージを作成する場合は、 globを以下のように使います:

この方法には注意すべき点があります. それは、インストールされたファイルを元にしてバイナリパッケージが作成され、コンフィグファイルをパッケージに含める際に問題となるかもしれないことです. システム管理者はパッケージをインストールした後にコンフィグファイルを編集することがあります. 重要な(、ひょっとしたら機密の)情報の漏洩を防止する観点から、はデフォルトでは CONFIG_PROTECT によって保護さされたコンフィグファイルをバイナリパッケージに含めません. これらのコンフィグファイルを含めるには、 or   オプションを使用してください.

emerge のオプションに --buildpkg を使用する
When installing software using, Portage can be asked to create binary packages by using   option:

It is also possible to ask Portage to only create a binary package but not to install the software on the live system. For this, the   option can be used:

しかしながら、後者のアプローチでは、すべてのビルド時依存が事前にインストールされている必要があります.

buildpkgをPortageの機能として実行する
パッケージがPortageによってインストールされるたびにバイナリパッケージを自動的に作成するもっとも一般的な方法は、以下のようにしてで設定できる 機能を利用することです:

この機能を有効にすると、Portageがソフトウェアをインストールするたびに、同様にバイナリパッケージも作成します.

いくつかのパッケージの作成を除外する
Portageに、いくつかの選択したパッケージやカテゴリについてバイナリパッケージを作成しないよう通知することができます. これは、 オプションをemergeに渡すことにより行います:

これは、バイナリパッケージを利用可能にすることにほとんど、あるいはまったく利益がないパッケージについて使用できます. 例として、Linuxカーネルソースパッケージやアップストリームのバイナリパッケージ(のように-binで終わるもの)があります.

バイナリパッケージホストを構成する
Portageは、バイナリパッケージのダウンロードのための多くのプロトコルをサポートしています: FTP、FTPS、HTTP、HTTPSおよびSSH. このことは、多くのバイナリパッケージホストの実装を可能にする余地を与えます.

しかしながら、Portageでは、バイナリパッケージを配布する"既存の枠組みから外れる"方法は提供されていません. 決めた構成によって、追加のソフトウェアのインストールが必要になるでしょう.

ウェブベースのバイナリパッケージホスト
バイナリパッケージを配布する一般的なアプローチの一つは、ウェブベースのバイナリパッケージホストを作成することです.

lighttpd のようなウェブサーバーを使用し、の PKGDIR ディレクトリへの読み込みアクセスを提供するよう設定します.

そして、クライアントシステムで、それに対応する PORTAGE_BINHOST 変数を設定します:

SSH バイナリパッケージホスト
バイナリパッケージへのより認証されたアプローチを提供するため、SSHの使用も考慮できます.

SSHを使用する場合、LinuxのrootユーザーのSSH鍵(インストールはバックグラウンドで行われる必要があるため、パスフレーズなしのもの)をリモートのバイナリパッケージホストへの接続に使用できます.

これを実現するには、rootユーザーのSSH鍵がサーバーで許可されていることを確認してください. これは、SSHに対応したバイナリホストに接続する各マシンのために行う必要があります:

そして、 PORTAGE_BINHOST 変数は以下のようになります:

NFSエクスポート
内部ネットワークでバイナリパッケージを使用する場合、パッケージをNFSを通じてエクスポートし、クライアントでそれをマウントするのがより簡単かもしれません.

ファイルは以下のようになります:

その後、クライアントでその場所をマウント可能です. エントリーの例は以下のようになります:

バイナリーパッケージを使用する
バイナリパッケージが他のシステムで利用可能であるためには、いくつかの要件を満たす必要があります:


 * クライアントとサーバーのアーキテクチャおよび CHOST は一致していなければなりません.
 * バイナリパッケージのビルドに使用された CFLAGS および CXXFLAGS 変数は、すべてのクライアントとの間で互換性がなければなりません.
 * プロセッサ特有の命令セット機能(たとえば、MMX、SSEなど)のためのUSEフラグは注意深く選択しなければなりません: すべてのクライアントがそれらをサポートしている必要があります.

次に、Portageは、バイナリパッケージがクライアントにおいて期待されるのと同じUSEフラグを用いてビルドされているかチェックします. パッケージが異なるUSEフラグの組み合わせでビルドされている場合、実行の際にコマンドに渡されたオプションによって、Portageはそのバイナリパッケージを無視する(そしてソースベースのビルドを使用する)か、あるいは失敗します(バイナリーパッケージをインストールするを参照してください).

クライアントでは、バイナリパッケージが使用されるようにするために、いくつかの設定の変更が必要です.

バイナリーパッケージをインストールする
に渡せる、Portageにバイナリパッケージの使用について通知するオプションがいくつかあります:

バイナリパッケージによるインストールを自動的に利用するために、適切なオプションを EMERGE_DEFAULT_OPTS 変数に追加することができます:

There is a Portage feature that automatically implements the equivalent of   without the need for updating the EMERGE_DEFAULT_OPTS variable with the   value:

パッケージをバイナリパッケージホストから取得する
バイナリパッケージホストを使用する場合、クライアントでは PORTAGE_BINHOST がセットされている必要があります. さもないと、クライアントはバイナリパッケージがどこに保管されているかわからず、Portageがそれらを取得できないという結果をもたらします.

PORTAGE_BINHOST 変数は、スペースで区切られたURIのリストを使用します. これにより、管理者は複数のバイナリパッケージサーバーを同時に使用できます. URIは、ファイルが存在するディレクトリを常に指していなければなりません.

改変したバイナリーパッケージを再インストールする
Passing the  option to  will reinstall every binary that has been rebuilt since the package was installed. This is useful in case rebuilding tools like are run on the binary package server.

関連するオプションの1つが です. これにより、emergeは与えられたタイムスタンプよりも前にビルドされたバイナリパッケージを再インストールにおいて考慮しなくなります. これは、バイナリパッケージサーバーはいちから再ビルドする必要があるが、その他の点で が使用される場合に、全てのパッケージが再インストールされるのを回避するために有用です.

追加のクライアント設定
機能に次いで、Portageは 機能にも対応します. この機能は、成功したバイナリパッケージのインストールについてのログファイルを保持するかどうかを制御します. これは PORT_LOGDIR 変数がセットされている場合のみ意味があり、またデフォルトでは有効化されています.

特定のパッケージやカテゴリのセットについてバイナリパッケージを除外するのと同様に、クライアントにおいて、特定のパッケージやカテゴリのセットについてバイナリパッケージのインストールを除外するように設定することができます.

これを実現するには、 オプションを使用します:

こうした追加の設定をemergeの実行ごとに有効にするには、ファイル内の EMERGE_DEFAULT_OPTS 変数にオプションを追加します:

バイナリーパッケージを管理する
バイナリパッケージのリストが活発に管理されていない場合、バイナリパッケージのエクスポートや配布はストレージの無駄な消費につながります.

不用なバイナリーパッケージを削除する
パッケージでは、というアプリケーションが提供されています. これにより、ダウンロードされたソースコードファイルのようなPortageに関する可変ファイルだけでなく、バイナリパッケージも管理することができます.

以下のコマンドは、該当するebuildがインストール済みebuildのリポジトリの中にないバイナリパッケージをすべて削除します:

詳細は Eclean の記事を読んでください.

もう一つの利用可能なツールは、パッケージのツールです. しかしながら、このツールはやや設定可能性において劣ります.

使用されていないバイナリパッケージ(バイナリパッケージが保管されているサーバーによって使用されているかという意味で)をクリーンアップするには:

Packages のファイルを管理する
パッケージディレクトリ内には、と呼ばれるマニフェストファイルが存在します. このファイルは、パッケージディレクトリ内のすべてのバイナリパッケージのメタデータのキャッシュとして機能します. このファイルは、Portageがバイナリパッケージをディレクトリに追加するたびに更新されます. 同様に、はバイナリパッケージを削除する際にこのファイルを更新します.

なんらかの理由でパッケージが単に削除されたりパッケージディレクトリにコピーされたりした場合、またはファイルが破損したり削除されたりした場合には、ファイルを再作成する必要があります. これにはコマンドを利用します:

パッケージディレクトリのスナップショットを作成する
多数のクライアントシステムへ向けてバイナリパッケージを配置する場合、パッケージディレクトリのスナップショットを作成する価値が出てきます. そうすると、クライアントシステムはパッケージディレクトリを直接使わず、バイナリパッケージのスナップショットを使用します.

スナップショットは、またはツールを使用して作成できます. このツールは4つの引数をとります:


 * 1) ソースディレクトリ(パッケージディレクトリへのパス)
 * 2) ターゲットディレクトリ(存在しないディレクトリである必要があります)
 * 3) URI
 * 4) バイナリパッケージサーバーディレクトリ

パッケージディレクトリのファイルはターゲットディレクトリへコピーされます. そして、ファイルが、バイナリパッケージサーバーディレクトリ(第四引数)内に、提供されたURIを用いて作成されます.

クライアントシステムは、バイナリパッケージサーバーディレクトリを指すURIを使う必要があります. そこから、に与えられたURIへとリダイレクトされます. このURIはターゲットディレクトリを参照していなければなりません.

バイナリパッケージの形式を理解する
Portageによって作成されたバイナリパッケージは、で終わるファイル名を持ちます. これらのファイルは2つの部分から成ります:


 * 1) システムへインストールされるファイルを含むアーカイブ
 * 2) パッケージのメタデータ、ebuild、そしてenvironmentファイルを含むアーカイブ

形式の詳細については、を参照してください.

に、およびファイルを分割、作成できるいくつかのツールがあります.

以下のコマンドは、をおよびファイルに分割します:

ファイルは、を使用して調査することができます.

内容をリストアップするには:

次のコマンドは、このパッケージについて有効化されているUSEフラグを含む、と呼ばれるファイルを抽出します:

PKGDIR の構成
現在使用されているバージョン2形式は、以下のような構成になっています:

ファイルは、最初のバイナリパッケージディレクトリ形式(バージョン1)からの主要な改善点です(また、Portageが、バイナリパッケージディレクトリがバージョン2を採用していると判断するためのトリガーでもあります). バージョン1では、すべてのバイナリパッケージは単一のディレクトリ内で提供されており、カテゴリのディレクトリにはディレクトリ内のバイナリパッケージへのシンボリックリンクのみが含まれていました.

quickunpkg を用いて展開する
Zoobab氏が、ファイルを素早く展開するためのシンプルなシェルツールquickunpkgを作成しました.