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

From Gentoo Wiki
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 のほかに、バイナリーパッケージの作成とインストールにも対応しています。 このガイドでは、バイナリーパッケージの作成方法、インストール方法、バイナリーパッケージサーバーのセットアップ方法について説明します。

はじめに

Gentoo 上にソフトウェアをインストールするために、システム管理者がバイナリパッケージを使用するのを好む場合には、多くの理由があります:

  1. 管理者が複数の同様のシステムを更新された状態に維持するときに、時間を節約することができます。 ソースからすべてをコンパイルする必要があるのは、時間の浪費になりえます。 もし、ただひとつのシステムですべてをコンパイルして他のシステムでバイナリパッケージを利用できれば、いくつかの似たようなシステム(そのうちいくらかには古いハードウェアがあるかもしれません)を管理するのはとても楽になるでしょう。
  2. 安全な更新を行う。 実稼働用のミッションクリティカルなシステムのためには、使用可能な状態で可能な限りありつづけることが重要です。 これは、すべての更新を一番最初に自分自身に行うステージングサーバーによって実現できます。 ステージングサーバが良好な状態になると、その次に更新が重要なシステムに適用することができます。 このアプローチの変化形として、同じシステムのchroot環境で更新を行い、そこで作成されたバイナリを実際のシステムで用いるという方法もあります。
  3. バックアップとして。 多くの場合、バイナリパッケージが壊れたシステム（すなわち、壊れたコンパイラ）を回復する唯一の方法です。 事前にコンパイルされたバイナリをバイナリパッケージサーバ上やローカルで持つことは、ツールチェーンが壊れた場合には大きな助けになるでしょう。
  4. 非常に古いシステムを更新する助けにもなります。 非常に古いシステムを更新する作業は、バイナリパッケージを使用することで大幅に楽になります。 バイナリパッケージではビルド時の依存関係を更新/インストールする必要がないので、通常は古いシステムにバイナリパッケージをインストールするのは助けになります。 また、バイナリパッケージは事前にコンパイルされているので、ビルド工程での失敗も避けられます。

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

  • バイナリパッケージを作成する。
  • バイナリパッケージをクライアントへ配信する。
  • バイナリパッケージを実装する。
  • バイナリパッケージを保守する。

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

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

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

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

  1. 通常のインストール後、 quickpkgのアプリケーションを使用する
  2. emerge時に--buildpkg (-b)オプションを明示する
  3. PortageのFEATURES変数で値buildpkgを使用して自動的に作成する

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

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 を使用する

emergeでソフトウェアをインストールするときに、 Portageに--buildpkg (-b)オプションを通すことによってバイナリパッケージを同時に作成することもできますː

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

システムにはソフトウェアをインストールせずに、バイナリパッケージのみを作成することもできます。この場合は--buildpkgonly (-B)オプションを通してください:

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

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

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

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

ファイル /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/SFTP。このことは、多くのバイナリパッケージホストの実装を可能にする余地を与えます。

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

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

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

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

ファイル /etc/lighttpd/lighttpd.conflighttpd の設定例
# add this to the end of the standard configuration
server.modules += ( "mod_alias" )
alias.url = ( "/packages" => "/var/cache/binpkgs/" )

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

ファイル /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変数は以下のようになります:

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

NFSエクスポート

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

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

ファイル /etc/exportsパッケージのディレクトリをエクスポート
/var/cache/binpkgs   2001:db8:81:e2::/48(ro,no_subtree_check,root_squash) 192.168.100.1/24(ro,no_subtree_check,root_squash)

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

ファイル /etc/fstabパッケージフォルダーのマウントの例
binhost:/var/cache/binpkgs      /var/cache/binpkgs    nfs    defaults    0 0

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

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

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

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

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

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

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

オプション 説明
--usepkg (-k) ローカルで使用可能なpackagesディレクトリ内のバイナリパッケージの利用を試みます。NFSやSSHFSでマウントされたバイナリパッケージホストを使用する場合に有用です。バイナリパッケージが見つからない場合は、通常の(ソースベースの)インストールが行われます。
--usepkgonly (-K) --usepkg (-k)と似ていますが、バイナリパッケージが見つけられない場合には失敗します。
--getbinpkg (-g) リモートのバイナリパッケージホストからバイナリパッケージをダウンロードします。バイナリパッケージが見つからない場合は、通常の(ソースベースの)インストールが行われます。
--getbinpkgonly (-G) --getbinpkg (-g)と似ていますが、バイナリパッケージがダウンロードできない場合には失敗します。このオプションは、pre-builtバイナリパッケージのみを利用したい場合に有用です。

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

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

EMERGE_DEFAULT_OPTS変数を--getbinpkgという値を用いて更新しなくても、--getbinpkg (-g)と同様のことを自動的に実行するPortageの機能があります:

ファイル /etc/portage/make.confFEATURES変数でgetbinpkgを有効化する
FEATURES="getbinpkg"

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

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

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

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

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

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

--rebuilt-binariesオプションをemergeに渡すと、パッケージがインストールされた後に再ビルドされたすべてのバイナリが再インストールされます。これは、revdep-rebuildのような再ビルドツールがバイナリパッケージサーバー上で実行された場合に有用です。

関連するオプションの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変数にオプションを追加します:

ファイル /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形式は、以下のような構成になっています:

コード パッケージディレクトリの構成(バージョン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://wiki.gentoo.org/index.php?title=Binary_package_guide/ja&oldid=1133311"