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

This page is a translated version of the page Binary package guide and the translation is 100% complete.

Other languages:

Portage - the heart of Gentoo
emerge — configuration — ebuild repository — dispatch-conf

world file — USE flags — ebuilds — profiles
upgrades — using testing packages — binary packages
tools — gentoolkit — eselect
Portage FAQ — cheat sheet — FAQ
all articles

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

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

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

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

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

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

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

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

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 の値を変更してください。

ファイル /etc/portage/make.confGPKG バイナリパッケージフォーマットを指定する

BINPKG_FORMAT="gpkg"

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

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

一般の前提条件

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

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

メモ
Gentoo 公式の Binhost project の一部として配布されるバイナリパッケージは、可能な限り広範囲で使用できるようにするために最小の命令セットと保守的なコンパイラ設定を使用しています。例として、amd64 キーワードが付けられたパッケージは -march=x86-64 -mtune=generic でビルドされ、これは x86-64 (amd64) 命令セットを実行するあらゆるマシンで動作します。

重要
Portage は、これらの要件が満たされているか検証することができません。疑念がある場合、これらの設定を守るのはシステム管理者の責任です。

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

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

user $resolve-march-native

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

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

user $resolve-march-native

 -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 などによってコンパイルされないパッケージを除外することができます:

user $

emerge -e @world --exclude="acct-group/* acct-user/* virtual/* app-eselect/* sys-kernel/* sys-firmware/* dev-python/* dev-java/* dev-ruby/* dev-perl/* dev-lua/* dev-php/* dev-tex/* dev-texlive/* x11-themes/* */*-bin"

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

user $cpuid2cpuflags

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

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

user $cpuid2cpuflags

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

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

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

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

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

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

ファイル /etc/portage/make.conf自動的にバイナリパッケージを取得し、パッケージが利用可能でない場合にはソースからビルドする

EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --getbinpkg"

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

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

FEATURES="getbinpkg"

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

重要
OpenPGP 署名と検証は GPKG binpkg フォーマットでのみ利用可能です。

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

root #getuto

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

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

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

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

ファイル /etc/portage/make.confPortage の binpkg-request-signature 機能を有効化する

FEATURES="binpkg-request-signature"

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

警告
「PORTAGE_BINHOST 変数は非推奨で、/etc/portage/binrepos.conf 設定ファイルが推奨されます」("The PORTAGE_BINHOST variable is deprecated in favor of the /etc/portage/binrepos.conf configuration file") - make.conf(5)

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

ファイル /etc/portage/binrepos.confbinhost sync-uri を設定する

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

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

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

メモ
複数のバイナリパッケージサーバーのサポートはやや不完全です。複数のサーバーが同じパッケージバージョンのバイナリパッケージを提供している場合、最初の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/*'"

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

重要
バイナリパッケージホスト上のパッケージを更新するときに --changed-use (-U) を使用しないでください。使用すると、USE フラグが追加または削除されたパッケージがスキップされ、ソース ebuild とバイナリパッケージの間で USE が一致しなくなるため、それらのパッケージをバイナリパッケージからクライアントにインストールするときに失敗する原因になります (クライアントがデフォルトに従って --binpkg-respect-use=y である場合)。--newuse (-N) を使用してください。こちらは USE フラグが追加または削除された場合であっても常にパッケージを再ビルドし、バイナリパッケージがソース ebuild と同期されている状態を保つでしょう。

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

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

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

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

quickpkg を利用する

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

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

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

root #quickpkg sys-devel/gcc

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

root #quickpkg @system

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

root #quickpkg "*/*"

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 "acct-*/* sys-kernel/*-sources virtual/*"

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

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

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

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

ファイル /etc/portage/make.confバイナリパッケージの圧縮フォーマットを指定する

BINPKG_COMPRESS="lz4"

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

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

重要
OpenPGP 署名と検証は GPKG binpkg フォーマットでのみ利用可能です。

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

ファイル /etc/portage/make.confPortage の binpkg-signing 機能を有効化する

FEATURES="binpkg-signing"

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

ファイル /etc/portage/make.confPortage の署名鍵を設定する

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

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

ファイル /etc/portage/make.confPortage の gpg-keepalive 機能を有効化する

FEATURES="gpg-keepalive"

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

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.dir-listing = "enable"
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 プロトコルを利用するように Portage を設定することできます。

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

ファイル /etc/portage/make.confPORTAGE_BINHOST をポート 25 での SSH アクセス用に設定する

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

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

NFS エクスポート

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

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

ファイル /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エントリーの例は以下のようになります:

ファイル /etc/fstabパッケージフォルダーのマウントの例

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

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

ファイル /etc/portage/make.confportage のためにパッケージディレクトリを設定する

PKGDIR="/var/cache/binpkgs"

メモ
PKGDIR がネットワークマウントされている場合、FEATURES="pkgdir-index-trusted" を有効化すると良いかもしれません。この機能は追加または削除されたパッケージの PKGDIR 全体でのチェックを無効化し、代わりに Packages ファイルの内容が正確なものであると信頼します。レイテンシの高いネットワーク上では、これにより劇的にパフォーマンスが改善されます。

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

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

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

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

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

root #rm -r /var/cache/binpkgs/*

高度な話題

chroot

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

メモ
この例では chroot 環境のパスとして /var/chroot/buildenv を使用していますが、どんなパスでも使用できます。

ディレクトリを作成する

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

root #mkdir --parents /var/chroot/buildenv

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

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

/var/chroot/buildenv/ #

wget https://bouncer.gentoo.org/fetch/root/all/releases/amd64/autobuilds/20230528T163158Z/stage3-amd64-desktop-openrc-20230528T163158Z.tar.xz

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

/var/chroot/buildenv/ #tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner

ビルド環境を設定する

重要
ターゲットホストが multilib を使用していて、ビルド側システムがそうでない場合は、multilib をサポートするようにカーネルを再ビルドする必要があります。

カーネル 32 ビットエミュレーションモードを有効化する

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 のファイルをコピーすることです。これは scp を使って行うことができます:

メモ
このコマンドはターゲットマシン上で、chroot 環境を含むリモートホストに対して実行すべきです。

user $rsync --archive --whole-file --verbose /etc/portage/* larry@remote_host:/var/chroot/buildenv/etc/portage

user $rsync --archive --whole-file --verbose /var/db/repos/* larry@remote_host:/var/chroot/buildenv/var/db/repos

メモ
この方法は larry がこの chroot 環境内に書き込み権限を持っていることを必要とします。この方法を使用する場合は、ターゲットディレクトリをクリアして、このディレクトリの所有者を larry にして、後で root が所有するように変更するのがよいでしょう。これらの権限は再帰的に変更すべきです:

root #chown --recursive root:root /var/chroot/buildenv/etc/portage

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

user $

rsync --archive --whole-file --verbose /var/lib/portage/world larry@remote_host:/var/chroot/buildenv/var/lib/portage/world

メモ
/var/lib/portage および /var/lib/portage/world は root:portage パーミッションを持つべきです。

chroot 環境を設定する

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

/var/chroot/buildenv #mount --types proc /proc proc

/var/chroot/buildenv #mount --rbind /dev dev

/var/chroot/buildenv #cp --dereference /etc/resolv.conf etc

メモ
portage の temp dirに tmpfs を使用している場合は、それがマウントされているか確認してください。

chroot 環境に入る

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

/var/chroot/buildenv #chroot . /bin/bash

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

/ #export PS1="(chroot) $PS1"

最初のビルドを実行する

メモ
このステップは buildpkg を使うように portage を設定するの設定が完了していることを前提としています。

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

(chroot) #emerge --emptytree @world

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

sys-devel/crossdev はクロスコンパイル用のツールチェーンを簡単にビルドするツールで、これを利用することで、例えば Raspberry Pi のようなデバイス向けによりパワフルなデスクトップ PC でビルドして提供する、という風に、異なるアーキテクチャ向けのバイナリホストを構成することができます。

このパッケージのインストールガイドは Crossdev ページで見つかります。

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

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

root #crossdev --stable -t arch-vendor-os-libc

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

root #crossdev --stable -t aarch64-unknown-linux-gnu

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

ヒント
Glibc ではなく Musl libc を使用するシステムをビルドするには、 aarch64-unknown-linux-gnu を aarch64-unknown-linux-musl で置き換えてください。

基本的なセットアップ

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

ファイル /usr/aarch64-unknown-linux-gnu/etc/portage/make.confpam USE フラグを無効化する

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/"

プロファイル

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

root #PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnu eselect profile list

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

root #PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnu eselect profile set <プロファイル番号>

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

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

root #emerge-aarch64-unknown-linux-gnu --ask foo

world ファイルをビルドする

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

root #emerge-aarch64-unknown-linux-gnu --emptytree @world

バイナリの場所

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

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

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

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

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

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

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

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

XPAK フォーマット

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

システムへインストールされるファイルを含む.tar.bz2アーカイブ
パッケージのメタデータ、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

GPKG フォーマット

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

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

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

PKGDIR の構成

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

コード パッケージディレクトリの構成(バージョン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 がデフォルトで有効化されています:

コード パッケージディレクトリの構成 (version 2 + 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を作成しました。

外部資料

quickpkg man ページ。