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

このガイドは バイナリパッケージ の作成、配布、使用、および保守について詳しく取り扱い、最後のほうではいくつかの高度な話題にも触れます。このページはGentoo の公式 binhost についても少しだけカバーしていますが、主に自分でビルドしたバイナリパッケージに焦点を当てています。

Portage は、よく知られたソースからの ebuild に加えて、バイナリパッケージにも完全に対応しています。Portage は、バイナリパッケージを作成したり、それらをインストールしたり、バイナリパッケージからすでにシステムにインストールされたパッケージを更新するために、使用することができます。Portage には、 バイナリパッケージホスト からバイナリパッケージを取得するためのサポートも備わっています。

なぜ Gentoo でバイナリパッケージを使用するのか?

システム管理者が Gentoo にバイナリパッケージをインストールするのを好むのには、多くの理由があります:

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

バイナリパッケージフォーマット

Gentoo で使用されるバイナリパッケージのフォーマットとして、XPAK と GPKG の 2 種類が存在しています。 v3.0.31 以降の Portage は、新しいバイナリパッケージフォーマットである GPKG に対応しています。GPKG フォーマットは、レガシーな XPAK フォーマットにまつわる問題を解決し、 新しい機能 の利点を提供していますが、レガシーな XPAK フォーマットとの後方互換性は ありません 。

これより古いバージョンの Portage (<=v3.0.30) を利用しているシステム管理者は、レガシーな XPAK フォーマットの使用を継続するべきです。これは対象のバージョンの Portage でのデフォルト設定です。

より新しい GPKG フォーマットの設計動機は GLEP 78: Gentoo binary package container format で確認することができます。バグ bug #672672 および bug #820578 もまた役に立つ詳細を提供しています。

新しい GPKG フォーマットを使用するように Portage に指示するには、 /etc/portage/make.conf で BINPKG_FORMAT の値を変更してください。Portage の現行バージョンはデフォルトで gpkg を使用することに注意してください。

BINPKG_FORMAT="gpkg"

このガイドでは特に注意の無い限り、両方のフォーマットを適用対象としています。バイナリパッケージフォーマット自体の技術的詳細については、 バイナリパッケージの形式を理解する の節を参照してください。

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

一般の前提条件

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

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

*FLAGS の取り扱いに関する詳細

サーバとクライアントの両方でサポートされている CFLAGS のサブセットを探すために、 app-misc/resolve-march-native ユーティリティを利用することができます。例えば、ホストが次を返すとします:

 -march=skylake -mabm -mrtm --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=12288 

一方でクライアントが返すのは:

 -march=ivybridge -mno-rdrnd --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=3072 

この例では、 CFLAGS は -march=ivybridge -mno-rdrnd に設定することができます、これは -march=ivybridge は -march=skylake の完全なサブセットであるためです。 -mabm と -mrtm は、クライアントでサポートされていないため、含まれません。しかしながら、クライアントが -mrdrnd をサポートしていないため、 -mno-rdrnd は含まれます。どの -march がどの -march のサブセットであるかを調べるには、 gcc マニュアル を確認してください。適切なサブセットが無い場合は、例えば -march=x86-64 を設定してください。

追加で、gcc に特定のアーキテクチャ向けにコードをチューンするように指示する -mtune= some-arch または -mtune=native を設定することもできます。 -march とは対照的に、 -mtune 引数によってコードが他のプロセッサで実行できなくなることはありません。例えば、 ivybridge 以降と互換性を持たせつつ、 skylake 上で最高の性能で実行できるようにチューンされたコードをコンパイルするには、 CFLAGS を -march=ivybridge -mtune=skylake に設定してください。 -mtune が設定されていない場合は、デフォルトとして -march が設定されている値に設定されます。

クライアントでバイナリパッケージを利用するために -march をより低いサブセットに変更したときには、すべてのバイナリがクライアントのプロセッサと互換性があることを確実にするために、システム全体の再コンパイルをが必要です。時間を節約するために、gcc/clang などによってコンパイルされないパッケージを除外することができます:

同様に、プロセッサ固有の命令セット USE フラグの適切なサブセットを探すために、 app-portage/cpuid2cpuflags を利用することができます。例えば、ホストが次を返すとします:

 CPU_FLAGS_X86: aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3 

一方でクライアントが返すのは:

 CPU_FLAGS_X86: avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 

この例では、 /etc/portage/make.conf 内で CPU_FLAGS_X86 を avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 に設定することができます。これらのフラグはクライアントとホストの両方でサポートされているからです。

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

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

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

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

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

EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --getbinpkg"

emerge に対して、バイナリパッケージホストからファイルを常に取得しようとすることを強制させる、Portage の機能があります:

FEATURES="getbinpkg"

EMERGE_DEFAULT_OPTS 変数内の --getbinpkg ( -g ) と同等 ではない ことに注意してください。特に、コマンドライン上で --getbinpkg=n としてもこの機能は無効化されません。

バイナリパッケージの OpenPGP 署名を検証する

Portage は可能であればいつでもバイナリパッケージの署名の検証を試みますが、そのためにはまず、信頼されたローカル鍵を構成する必要があります。 app-portage/getuto は、ローカルのトラストアンカーをセットアップし、 /etc/portage/gnupg 内の鍵を更新するために使用することができます。 --getbinpkg または --getbinpkgonly を使用すると、Portage は自動的に getuto を呼び出します。

これはバイナリインストールの目的のために、 sec-keys/openpgp-keys-gentoo-release にも含まれている Gentoo Release Engineering keys を信頼するように portage を設定します。

設定の変更は、 gpg を --homedir=/etc/portage/gnupg パラメータ付きで、root として使用することで行うこともできます。 この方法を使用して、追加の署名鍵 (非標準のインストールソースの鍵など) をインポートして信頼済みとして宣言することができます。

カスタム署名鍵を追加するには:

1. 署名能力を持つ鍵を生成 (または既存の鍵を使用) して、ファイルに公開鍵をエクスポートしてください。
2. 一度も実行していない場合は、 getuto を実行してください:
   root # getuto
3. gpg --homedir=/etc/portage/gnupg --import public.key を使用して、Portage のキーリングに公開鍵をインポートしてください。
4. この鍵を信頼して、 getuto によって作成された鍵を使用して署名してください。これを行うためには、まず鍵をアンロックするためのパスワードを /etc/portage/gnupg/pass から取得して、次を使用してください:
   root # gpg --homedir=/etc/portage/gnupg --edit-key YOURKEYID
   sign 、 yes と入力し、パスワードを貼り付けて (または入力して) ください。これで鍵が署名されました。これを信頼するには、 trust を入力し、そして完全に信頼するために 4 を入力してください。最後に、 save と入力してください。
5. GPG がその鍵を妥当とみなすことができるように、trustdb を更新してください:
   root # gpg --homedir=/etc/portage/gnupg --check-trustdb

問題に遭遇した場合は、既存の /etc/portage/gnupg が存在していないか確認してください。存在する場合は、別の場所に移動してから上の手順を繰り返してください。

おめでとうございます、これで機能するキーリングを Portage に設定できました!

デフォルトでは、Portage は署名ファイルがパッケージ内で見つかる場合のみ GPG 署名を検証しようとします。これにより、異なる入手元からの署名された GPKG バイナリパッケージと署名されていない GPKG バイナリパッケージを混ぜることができるようになり、古い XPAK フォーマットのバイナリパッケージも使うことができるようになります。

署名の検証を強制したい場合は、 binpkg-request-signature 機能を有効化する必要があります。この機能はすべてのパッケージが署名されるべきであると仮定し、署名されていないパッケージはすべて拒否します。この機能はバイナリパッケージホスト単位の設定をサポートしていないことに注意してください。

# すべてのバイナリパッケージが署名されていることを要求し、署名されていない (または不正な署名を持つ) 場合は拒否する
FEATURES="binpkg-request-signature"

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

バイナリパッケージホストを使用する場合、クライアントでは /etc/portage/make.conf 内で変数 PORTAGE_BINHOST がセットされているか、 または /etc/portage/binrepos.conf 内で変数 sync-uri がセットされている必要があります。この設定がされていないと、クライアントはバイナリパッケージがどこに保管されているかわからず、Portage がそれらを取得できないという結果をもたらします。

[binhost]
sync-uri = https://example.com/binhost
priority = 10

バイナリパッケージホストごとに、名前を角かっこでくくって設定することができます。 sync-uri は、 Packages ファイルが存在するディレクトリを指していなければなりません。追加で、優先度 ( priority ) を設定することができます。パッケージが複数のバイナリパッケージリポジトリに存在する場合、もっとも高い優先度を持つバイナリパッケージホストからパッケージが取得されます。このようにして、より優先されるバイナリパッケージホストを構成することができます。

多くの Gentoo stage には既にインストール済みの /etc/portage/binrepos.conf ファイルが付属しており、これは stage のビルド中に生成されたパッケージに対応するバイナリパッケージを指しています。

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

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

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

追加のクライアント設定

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

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

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

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

EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkg-exclude 'sys-kernel/gentoo-sources virtual/*'"

バイナリパッケージホスト上のパッケージを更新する

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

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

1. 通常のインストール後、 quickpkg のアプリケーションを使用する
2. emerge 時に --buildpkg ( -b ) オプションを明示する
3. Portage の FEATURES 変数の値 buildpkg (すべてのパッケージについてバイナリパッケージをビルドする) または buildsyspkg ( system 集合 についてのみバイナリパッケージをビルドする) を使用して自動的に作成する

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

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

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

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

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

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

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

FEATURES="buildpkg"

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

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

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

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

バイナリパッケージの圧縮フォーマット

バイナリパッケージについて、圧縮タイプを指定して利用することができます。現在サポートされているフォーマットは、 bzip2 、 gzip 、 lz4 、 lzip 、 lzop 、 xz 、そして zstd です。デフォルトは zstd です。最新の情報については man make.conf を確認し、 BINPKG_COMPRESS を検索してください。

圧縮フォーマットは make.conf から指定できます。

BINPKG_COMPRESS="lz4"

使用する圧縮タイプによっては、追加の依存関係をインストールする必要がある場合があります。例えば上の場合は app-arch/lz4 が必要です。

バイナリパッケージの OpenPGP 署名

PGP 署名を利用することで、Portage はバイナリパッケージの作成者と整合性をチェックすることができ、PGP 鍵に基づくトラストマネジメントを実施することができます。バイナリパッケージの署名機能はデフォルトでは 無効化されています 。これを使用するには binpkg-signing 機能を有効化してください。この機能が有効化されているかどうかは、署名の検証機能には影響しません。

FEATURES="binpkg-signing"

Portage が署名鍵を見つけられるように、 BINPKG_GPG_SIGNING_GPG_HOME と BINPKG_GPG_SIGNING_KEY 変数も設定する必要があります。

BINPKG_GPG_SIGNING_GPG_HOME="/root/.gnupg"
BINPKG_GPG_SIGNING_KEY="0x1234567890ABCDEF"

Portage は PGP 秘密鍵を開始時にのみアンロックしようとします。時間が経ってユーザの鍵の期限が切れてしまう場合、署名の失敗を防ぐために gpg-keepalive を有効化することを検討してください。

FEATURES="gpg-keepalive"

quickpkg を利用する

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

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

system 集合に含まれるパッケージのバイナリパッケージを作成するには:

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

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

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

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

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

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

HTTPD

www-servers/lighttpd をインストールし、 /etc/portage/make.conf の PKGDIR ディレクトリへの読み込みアクセスを提供するよう設定します。

# add this to the end of the standard configuration
server.dir-listing = "enable"
server.modules += ( "mod_alias" )
alias.url = ( "/packages" => "/var/cache/binpkgs/" )
dir-listing.activate = "enable" # optional: keep it, if you want to have a nice listing at web page at the /packages path.

Caddy

web ベースのバイナリパッケージホストを提供するために Caddy HTTP サーバをセットアップするには、以下の内容を含む Caddyfile を作成してください:

x.x.x.x:80 { # x.x.x.x は使用中のホストの IPv4 アドレスで置き換えてください
    root * /path/to/binhost/var/cache/binpkgs
    file_server browse # サーバには必要です
}

作成できたら、以下で Caddy を実行してください:

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

PORTAGE_BINHOST="http://binhost.example.com/packages"

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

バイナリパッケージミラーへの認証されたアプローチを提供するために、バイナリパッケージにアクセスするために SSH プロトコルを利用するように Portage を設定することできます。

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

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

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

PORTAGE_BINHOST="ssh://binpkguser@binhostserver/var/cache/binpkgs"

SSH サーバがデフォルトと異なるポート (例えば 25) で listen している場合は、次のようにアドレスの後に指定する必要があります:

PORTAGE_BINHOST="ssh://binpkguser@binhostserver:25/var/cache/binpkgs"

NFS エクスポート

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

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

/var/cache/binpkgs   2001:db8:81::/48(ro,no_subtree_check,root_squash) 192.168.100.0/24(ro,no_subtree_check,root_squash)

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

binhost:/var/cache/binpkgs      /var/cache/binpkgs    nfs    defaults    0 0

NFS 共有はローカルファイルシステム上にマウントされるので、 PORTAGE_BINHOST を設定したり --getbinpkg オプションを使用する必要はありません。代わりに、portage がどこからパッケージを探せばいいか分かるように、 PKGDIR が NFS 共有を指すようにして、 バイナリパッケージをインストールする ための通常の手続きに従ってください:

PKGDIR="/var/cache/binpkgs"

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

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

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

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

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

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

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

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

Packages のファイルを管理する

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

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

すべての バイナリパッケージのキャッシュをクリアするには:

高度な話題

chroot

異なる Portage プロファイル 向けに、または異なる USE フラグを持つシステム向けにパッケージを作成する場合は、 chroot 環境を作成して行うことができます。

ディレクトリを作成する

まずはこの chroot 環境のためのディレクトリを作成する必要があります:

ビルド環境をデプロイする

次に、適切な stage 3 tarball をダウンロードおよび展開する必要があります。ここでは desktop profile | openrc tarball を使用しています:

これは次のコマンドで展開することができます:

ビルド環境を設定する

Binary Emulations --->
  [*] IA32 Emulation
General architecture-dependent options --->
  [*] Provide system calls for 32-bit time_t

CONFIG_IA32_EMULATION=y
CONFIG_COMPAT_32BIT_TIME=y

ビルド環境の設定は、ターゲットとなるシステムの構成に合わせて行うべきです。これを行うための最も簡単な方法は、 /etc/portage と /var/lib/portage/world のファイルをコピーすることです。これは rsync を使って行うことができます:

この過程を world ファイルについても繰り返してください:

chroot 環境を設定する

chroot 環境を作成したら、それを機能させるためにバインドマウントを設定する必要があります:

chroot 環境に入る

この chroot 環境に入るためには、以下のコマンドを使用することができます:

必須ではありませんが、chroot がアクティブであることを反映したプロンプトを設定することができます:

最初のビルドを実行する

このステップは省略可能ですが、新しい world のすべてのパッケージを再ビルドします:

他のアーキテクチャ向けにビルドする

crossdev はクロスコンパイル用のツールチェーンを簡単にビルドするツールです。これは、パッケージをビルドするシステムのアーキテクチャとは異なる アーキテクチャ のシステムにインストールするためのバイナリパッケージを作成するのに有用です。よくある例としては、 arm64 の Raspberry Pi のようなデバイス向けのバイナリパッケージを、よりパワフルな amd64 デスクトップ PC でビルドすることが挙げられるでしょう。

sys-devel/crossdev のインストールガイドは crossdev ページで見つかります。

クロスコンパイラをビルドする

次のコマンドで crossdev を使用することで、希望するシステム向けのツールチェーンをビルドすることができます:

このセクションではこれ以降、ターゲットとして Raspberry Pi 4 を例に取ります:

ビルドが完了したら、素の Gentoo インストールと同じような見た目をしたツールチェーンが /usr/aarch64-unknown-linux-gnu に作成され、そこでは通常通りに Portage 設定を編集することができます。

基本的なセットアップ

このようなセットアップでは、 /usr/aarch64-unknown-linux-gnu/etc/portage/make.conf 内の USE の行から -pam フラグを削除することが一般的に推奨されます:

CHOST=aarch64-unknown-linux-gnu
CBUILD=x86_64-pc-linux-gnu
 
ROOT=/usr/${CHOST}/
 
ACCEPT_KEYWORDS="${ARCH}"
 
USE="${ARCH}"
 
CFLAGS="-O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
 
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# 他のリポジトリのパッケージが上書きされないようにする
PKGDIR=${ROOT}var/cache/binpkgs/
 
# PORTAGE_TMPDIR を再定義したい場合は、次の行のコメントアウトを解除して (必要であればディレクトリの場所も変更して) ください
PORTAGE_TMPDIR=${ROOT}var/tmp/
 
PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/var/db/repos/local/"

プロファイル

次を実行して、デバイスで利用可能なプロファイルを一覧表示してください:

次に、最適なプロファイルを選択してください:

単一のパッケージをビルドする

デバイス上で使用するために単一のバイナリパッケージをビルドするには、次を使用してください:

world ファイルをビルドする

world ファイル内のすべてのパッケージをビルドするには、次のコマンドが必要です:

バイナリの場所

デフォルトでは、すべてのバイナリパッケージは /usr/aarch64-unknown-linux-gnu/var/cache/binpkgs に保存されるので、ここが バイナリパッケージホストを構成する ときに選択する必要のある場所です。

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

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

スナップショットは、Portage に付属する /usr/lib/portage/python3.11/binhost-snapshot ツールを使用して作成できます (ツールのパスは Portage のインストールに使用された python バージョンと一致するように修正する必要があるかもしれません)。このツールは4つの引数をとります:

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

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

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

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

XPAK フォーマット

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

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

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

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

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

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

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

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

GPKG フォーマット

Portage によって作成された GPKG フォーマットのバイナリパッケージは、 .gpkg.tar で終わるファイル名を持ちます。これらのファイルは少なくとも 4 つの部分から成ります:

1. フォーマットを特定するために使用される、 gpkg-1 空ファイル。
2. パッケージメタデータ、ebuild、そして環境ファイルを含む、 C/PV/metadata.tar{.compression} アーカイブ。
3. システム上にインストールされるファイルを含む、 C/PV/image.tar{.compression} アーカイブ。
4. ファイルの破損から保護するためのチェックサムを含む、 Manifest ファイル。
5. 整合性チェックと信頼検証のために使用される OpenPGP 署名を含む、複数の任意の .sig ファイル。

このフォーマットは、追加ツールの必要なく tar によって展開することができます。

PKGDIR の構成

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

PKGDIR
`+- Packages
 +- app-accessibility/
 |  +- pkg1-version.tbz2
 |  `- pkgN-version.tbz2
 +- app-admin/
 |  `- ...
 `- ...

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

portage-3.0.15 以降は、 FEATURES=binpkg-multi-instance がデフォルトで有効化されています:

PKGDIR
`+- Packages
 +- app-accessibility/
 |  +- pkg1/
 |    +- pkg1-version-build_id.xpak
 |    `- pkgN-version-build_id.xpak
 +- app-admin/
 |  `- ...
 `- ...

quickunpkg を用いて展開する

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

/usr/libexec/gcc/x86_64-pc-linux-gnu/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../lib64/libSPIRV-Tools-opt.so: undefined reference to `std::ios_base_library_init()@GLIBCXX_3.4.32

関連項目

• Binary package quickstart — using the fully-supported Gentoo binary package host for amd64 and arm64 with the settings the packages are compiled with
• Emerge — Portage との、主たるコマンドラインインターフェース
• Portage — Gentoo のための公式の パッケージマネージャ であり、 ディストリビューションシステム です。
• Project:Binhost — aims to provide readily installable, precompiled packages for a subset of configurations, via central binary package hosting

外部資料

quickpkg man ページ。