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

バイナリーパッケージガイド

From Gentoo Wiki (test)
Jump to:navigation Jump to:search
This page is a translated version of the page Binary package guide and the translation is 100% complete.
Other languages:

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.

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

Note
このガイドで使用するツールは、特に断りがなければ、すべてsys-apps/portageに含まれます。

バイナリパッケージを作成する

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

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

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

quickpkg を利用する

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

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

root #quickpkg sys-devel/gcc

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

root #quickpkg "*/*"

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

emerge のオプションに --buildpkg を使用する

When installing software using emerge, Portage can be asked to create binary packages by using --buildpkg (-b) option:

root #emerge --ask --buildpkg sys-devel/gcc

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 --buildpkgonly (-B) option can be used:

root #emerge --ask --buildpkgonly sys-devel/gcc

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

buildpkgをPortageの機能として実行する

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

FILE /etc/portage/make.confPortageのbuildpkg機能を有効化する
FEATURES="buildpkg"

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

いくつかのパッケージの作成を除外する

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

root #emerge -uDN @world --buildpkg --buildpkg-exclude "virtual/* sys-kernel/*-sources"

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

バイナリパッケージホストを構成する

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

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

ウェブベースのバイナリパッケージホスト

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

lighttpd (www-servers/lighttpd)のようなウェブサーバーを使用し、/etc/portage/make.confのPKGDIRディレクトリへの読み込みアクセスを提供するよう設定します。

FILE /etc/lighttpd/lighttpd.conflighttpd の設定例
# add this to the end of the standard configuration
server.modules += ( "mod_alias" )
alias.url = ( "/packages" => "/usr/portage/packages/" )

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

FILE /etc/portage/make.confウェブベースのバイナリパッケージホストを使用する
PORTAGE_BINHOST="http://binhost.example.com/packages"

SSH バイナリパッケージホスト

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

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

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

root #cat root.id_rsa.pub >> /home/binpkguser/.ssh/authorized_keys

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

FILE /etc/portage/make.confPORTAGE_BINHOSTをSSHアクセス用に設定する
PORTAGE_BINHOST="ssh://binpkguser@binhostserver/usr/portage/packages"
Note
~/.ssh/configにあるSSH設定ファイルをポートやユーザー名の設定に使用しないでください。この場所はPortageがクライアントへのパッケージのrsyncを試みる際には無視されます。その代わりに、すべてのオプションをPORTAGE_BINHOST変数に正しくセットしてください。

NFSエクスポート

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

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

FILE /etc/exportsパッケージのディレクトリをエクスポート
/usr/portage/packages   2001:db8:81:e2::/48(ro,no_subtree_check,root_squash) 192.168.100.1/24(ro,no_subtree_check,root_squash)

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

FILE /etc/fstabパッケージフォルダーのマウントの例
binhost:/usr/portage/packages      /usr/portage/packages    nfs    defaults    0 0

バイナリーパッケージを使用する

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

  • クライアントとサーバーのアーキテクチャおよびCHOSTは一致していなければなりません。
  • バイナリパッケージのビルドに使用されたCFLAGSおよびCXXFLAGS変数は、すべてのクライアントとの間で互換性がなければなりません。
  • プロセッサ特有の命令セット機能(たとえば、MMX、SSEなど)のためのUSEフラグは注意深く選択しなければなりません: すべてのクライアントがそれらをサポートしている必要があります。
Important
Portageは、これらの要件が満たされているか検証することができません。これらの設定を守るのはシステム管理者の責任です。

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

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

バイナリーパッケージをインストールする

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

Option Description
--usepkg (-k) Tries to use the binary package(s) in the locally available packages directory. Useful when using NFS or SSHFS mounted binary package hosts. If the binary packages are not found, a regular (source-based) installation will be performed.
--usepkgonly (-K) Similar to --usepkg (-k) but fail if the binary package cannot be found. This option is useful if only pre-built binary packages are to be used.
--getbinpkg (-g) Download the binary package(s) from a remote binary package host. If the binary packages are not found, a regular (source-based) installation will be performed.
--getbinpkgonly (-G) Similar to --getbinpkg (-g) but will fail if the binary package(s) cannot be downloaded. This option is useful if only pre-built binary packages are to be used.

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

FILE /etc/portage/make.conf自動的にバイナリパッケージを取得し、パッケージが利用可能でない場合には失敗する
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --getbinpkgonly"

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

FILE /etc/portage/make.confFEATURES変数でgetbinpkgを有効化する
FEATURES="getbinpkg"

パッケージをバイナリパッケージホストから取得する

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

FILE /etc/portage/make.confPORTAGE_BINHOSTをセットする
PORTAGE_BINHOST="http://binhost.example.com/packages"

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

Note
複数のバイナリパッケージサーバーのサポートはやや不完全です。複数のサーバーが同じパッケージバージョンのバイナリパッケージを提供している場合、最初の1つのみが考慮されます。このことは、それらのバイナリパッケージでUSE変数の設定に違いがあり、かつ後の方のバイナリパッケージのUSE変数の設定がシステムの設定と一致する場合に問題となりえます。

改変したバイナリーパッケージを再インストールする

Passing the --rebuilt-binaries option to emerge will reinstall every binary that has been rebuilt since the package was installed. This is useful in case rebuilding tools like revdep-rebuild are run on the binary package server.

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

追加のクライアント設定

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

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

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

root #emerge -uDNg @world --usepkg-exclude "sys-kernel/gentoo-sources virtual/*"

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

FILE /etc/portage/make.confemergeの設定をすべての実行で有効化する
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkg-exclude 'sys-kernel/gentoo-sources virtual/*'"

バイナリーパッケージを管理する

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

不用なバイナリーパッケージを削除する

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

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

root #eclean packages

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

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

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

root #qpkg -c

Packages のファイルを管理する

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

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

root #emaint binhost --fix

高度な話題

パッケージディレクトリのスナップショットを作成する

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

スナップショットは、/usr/lib64/portage/python2.7/binhost-snapshotまたは/usr/lib64/portage/python3.3/binhost-snapshotツールを使用して作成できます。このツールは4つの引数をとります:

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

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

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

バイナリパッケージの形式を理解する

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

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

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

app-portage/portage-utilsに、tbz2およびxpakファイルを分割、作成できるいくつかのツールがあります。

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

user $qtbz2 -s <package>.tbz2

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

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

user $qxpak -l <package>.xpak

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

user $qxpak -x package-manager-0.xpak USE

PKGDIR の構成

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

CODE パッケージディレクトリの構成(バージョン2)
PKGDIR
`+- Packages
 +- app-accessibility/
 |  +- pkg1-version.tbz2
 |  `- pkgN-version.tbz2
 +- app-admin/
 |  `- ...
 `- ...

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

quickunpkg を用いて展開する

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

Retrieved from "https://wikitest.gentoo.org/index.php?title=Binary_package_guide/ja&oldid=736686"