Makepkg

関連記事

• パッケージの作成
• PKGBUILD
• .SRCINFO
• Arch User Repository
• pacman
• 公式リポジトリ
• Arch Build System

makepkg はパッケージのビルドを自動化するスクリプトです。makepkg スクリプトを使用するにはビルドが出来る Unix プラットフォームと PKGBUILD が必要です。

makepkg は pacman パッケージの中に入っています。

設定

makepkg の設定オプションについて詳しくは makepkg.conf(5) を参照してください。

/etc/makepkg.conf が makepkg のメインの設定ファイルです。ユーザー個別の設定は $XDG_CONFIG_HOME/pacman/makepkg.conf または ~/.makepkg.conf で可能です。パッケージをビルドする前に makepkg の設定オプションを微調整するとよいでしょう。

パッケージ作成者の情報

パッケージにはメタデータが付与されておりパッケージ作成者を識別することができます。デフォルトでは、ユーザーがコンパイルしたパッケージは Unknown Packager となります。システム上の複数のユーザーがパッケージをコンパイルする場合、あるいはパッケージを他者に配布する場合、実際の連絡先を入力すると便利です。makepkg.conf の PACKAGER 変数で設定することができます。

インストールしたパッケージの作成者情報を確認するには:

$ pacman -Qi package

[...]
Packager       : John Doe <john@doe.com>
[...]

生成したパッケージに自動的に署名するには makepkg.conf で GPGKEY 変数を設定してください。

パッケージの出力

デフォルトでは makepkg はパッケージ tarball を作業ディレクトリに作成し、ソースデータを src/ ディレクトリに直接ダウンロードします。カスタムパスを設定することで、例えばビルドしたパッケージを ~/build/packages/ に、ソースを全て ~/build/sources/ に保存することができます。

必要に応じて以下の makepkg.conf 変数を設定してください:

• PKGDEST — 生成したパッケージを保存するディレクトリ。
• SRCDEST — ソース データを保存するディレクトリ (別の場所を指定すると src/ へのシンボリックリンクが作成されます)
• SRCPKGDEST — 生成したソースパッケージを保存するディレクトリ (makepkg -S でビルド)

ヒント: PKGDEST ディレクトリのキャッシュを削除する方法は pacman#パッケージキャッシュの削除 を参照してください。例: paccache -r -c ~/build/packages/

署名チェック

ノート: makepkg で実装されている署名チェックは pacman のキーリングを使用しません [1] 代わりにユーザーのキーリングが使われます。

.sig または .asc の形式の署名ファイルが PKGBUILD ソース配列の一部である場合、makepkg は自動的に 検証 を試みます。ユーザーのキーリングに署名の検証に必要な公開鍵が含まれていない場合、makepkg は PGP 鍵を検証できなかったというメッセージを表示してインストールを中止します。

パッケージに必要な公開鍵が欠落している場合、PKGBUILD には必要な鍵 ID を持つ validpgpkeys エントリが含まれている可能性が高くなります。その場合手動で インポート 、または 鍵サーバー上 で見つけてそこからインポートします。署名チェックを一時的に無効にするには、--skippgpcheck オプションを指定して makepkg を実行します。

使用方法

続行する前に、base-devel グループを インストール してください。このグループに属するパッケージは、PKGBUILD ファイルでビルド時の依存関係 (makedepends) としてリストする必要はありません。

ノート:

• pacman に渡されるコマンドに対して sudo が適切に設定されていることを確認してください。
• makepkg 自体を root として実行することは 許可されていません.[2] PKGBUILD に任意のコマンドが含まれる可能性があることに加えて、root としてビルドすることは一般的に安全ではないと考えられています。[3] 通常のユーザー アカウントにアクセスできないユーザーは、nobody user として makepkg を実行する必要があります。

パッケージをビルドするには、パッケージの作成 で説明されているように、まず PKGBUILD またはビルド スクリプトを作成する必要があります。既存のスクリプトは、Arch Build System (ABS) ツリーまたは AUR から入手できます。 PKGBUILD を取得したら、それが保存されているディレクトリに移動し、次のコマンドを実行してパッケージをビルドします。

$ makepkg

必要な依存関係が欠落している場合、makepkg は失敗する前に警告を発します。パッケージをビルドして必要な依存関係をインストールするには、フラグ -s/--syncdeps を追加します。

$ makepkg --syncdeps

-r/--rmdeps フラグを追加すると、makepkg は後で不要になった make 依存関係を削除します。常にパッケージをビルドしている場合は、Pacman ヒント#使用していないパッケージの削除 (孤立したパッケージ) を時々使用することを検討してください。

ノート:

• これらの依存関係は、構成されたリポジトリで利用可能である必要があります。詳細は pacman#リポジトリとミラー を参照してください。または、ビルドの前に依存関係を手動でインストールすることもできます (pacman -S --asdeps dep1 dep2)
• 依存関係をインストールするときは、グローバル値のみが使用されます。つまり、分割パッケージのパッケージング関数で行われたオーバーライドは使用されません。

すべての依存関係が満たされ、パッケージが正常にビルドされると、パッケージファイル (pkgname-pkgver.pkg.tar.zst) が作業ディレクトリに作成されます。インストールするには、-i/--install を使用します (pacman -U pkgname-pkgver.pkg.tar.zst):

$ makepkg --install

$srcdir に抽出されたファイルなど、残りのファイルとディレクトリをクリーンアップするには、オプション -c/--clean を追加します。これは、同じビルド ディレクトリを使用しながら、同じパッケージの複数のビルドやパッケージバージョンの更新に役立ちます。古いファイルや残りのファイルが新しいビルドに引き継がれるのを防ぎます。

$ makepkg --clean

詳細については、makepkg(8) を参照してください。

ヒントとテクニック

ソースのダウンロードと抽出の時間を短縮する

ソースの場所の定義

特に VCSパッケージ をビルドするときに SRCDEST を利用すると、以降のリビルドでソースの取得や展開にかかる時間を短縮できます。

git フラグをオーバーライドする

大幅な高速化を実現する 1 つとしては、部分クローンを使用することです。Git --filter=tree:0 フラグを使用すると、オンデマンドでのみソースツリーを更新できます。GITFLAGS 変数を使用して、これを makepkg に渡すことができます。

ノート: pacman 6.0.2 の時点では、GITFLAGS のサポートは Makepkg の現在の安定バージョンにまだマージされていません。使用するには開発版の Pacman (例: pacman-git^AUR) が必要です。

例:

$ GITFLAGS="--filter=tree:0" makepkg

または、すべてのビルドに適用するには:

/etc/makepkg.conf

GITFLAGS="--filter=tree:0"

ノート: 現時点 (2023 年) では、まだすべての git サーバーがこのフラグをサポートしているわけではありません。

また、--single-branch も通常は安全ですが、それほど節約できません。フラグの詳細については、git-clone(1) を参照してください。

警告: git フラグに あらゆる 変更を加えると破損が生じる可能性があることに注意してください。PKGBUILD は、現在の Makepkg のデフォルトに依存して、予期しない方法で git を利用する可能性があります。 浅いクローン (例: -- Depthテンプレート:=1) の使用を提案する人もいますが、実際には VCS の pkgver() が壊れてしまいます。パッケージなど。これについては、ここ のように、すでに何度も議論されています。

最適化されたパッケージの作成

makepkg のデフォルトでは、様々なマシンでインストールできるような一般的なパッケージを生成するようにオプションが設定されています。ホストマシンにあわせてコンパイラの最適化を有効化することで、パッケージ化するソフトウェアの性能を向上させることができます。ただし特定のプロセッサアーキテクチャにあわせてパッケージをコンパイルした場合、他のマシンでは正しく動作しなくなります。x86_64 のマシンでは、時間を投資して公式のパッケージをリビルドすることでそれに見合うだけのパフォーマンスの向上を得られることは稀です。

標準外のコンパイラフラグを使うことでパフォーマンスが劣化する可能性も十分あります。ほとんどのコンパイラオプションは特定の状況でのみ有効であり、無差別に全てのパッケージに適用しないほうが良いでしょう。何かが速くなると確認・ベンチマークできない限り、無駄にコンパイラオプションを使わないことを推奨します。Gentoo の コンパイル最適化ガイド や 安全な CFLAGS 記事にはコンパイラの最適化に関する詳しい解説が載っています。

C/C++ コンパイラ (例: gcc や clang) に渡されるオプションは CFLAGS, CXXFLAGS, CPPFLAGS 環境変数で制御されます。同じように make ビルドシステムは MAKEFLAGS を使います。Arch のビルドシステムでは makepkg.conf の設定オプションとして makepkg はこれらの環境変数を使用します。デフォルト値は幅広いマシンにインストールできる汎用のパッケージを作成するように設定されています。

ノート: 全てのビルドシステムが makepkg.conf に設定した変数を使うわけではないということに注意してください。例えば cmake はプリプロセッサオプションの環境変数 CPPFLAGS を無視します。多くの PKGBUILD にはパッケージ化するソフトウェアによって使われているビルドシステム固有のオプションが含まれています。

GCC はアーキテクチャ固有の最適化を自動で認識・有効化することができます。自動最適化を使用するには、-march と -mtune フラグを全て削除してから -march=native を追加してください。例:

CFLAGS="-march=native -O2 -pipe -fstack-protector-strong"
CXXFLAGS="${CFLAGS}"

march=native フラグによってどのフラグが有効になるのか確認するには、次のコマンドを実行してください:

$ gcc -march=native -v -Q --help=target

ノート:

• -march=native 以外の値を指定した場合、-Q --help=target は期待通りに機能しなくなります [4]。どのオプションが実際に有効になるのかはコンパイルを行わないと分かりません。詳しくは Gentoo wiki の Find CPU-specific options を参照。
• gcccpuopt スクリプトを使うことで 32ビットの x86 アーキテクチャの最適化オプションを確認することができます。

ビルド時間を短縮する

並列コンパイル

make ビルドシステムは、MAKEFLAGS 環境変数 を使用して、make の追加オプションを指定します。 変数は、 makepkg.conf ファイルでも設定できます。

マルチコア/マルチプロセッサシステムを使用しているユーザーは、同時に実行するジョブの数を指定できます。 これは、 nproc を使用して使用可能なプロセッサの数を決定することで実現できます。 MAKEFLAGS="-j $(nproc)" 一部の PKGBUILD は、特定のバージョンの競合状態のため、または単に最初からサポートされていないため、これを -j1 で具体的にオーバーライドします。 このためにビルドに失敗したパッケージは、エラーが実際に発生していることを確認した後、バグトラッカー(またはAURパッケージの場合はパッケージメンテナ)に 報告 して下さい MAKEFLAGS が原因です。

使用可能なオプションの完全なリストについては、 make(1) を参照してください。

メモリ内のファイルからビルドする

コンパイルには多くの I/O 操作と小さなファイルの処理が必要なため、作業ディレクトリを tmpfs に移動すると、ビルド時間が早くなる可能性があります。

BUILDDIR 変数を一時的に makepkg にエクスポートして、ビルドディレクトリを既存の tmpfs に設定できます。例えば:

$ BUILDDIR=/tmp/makepkg makepkg

永続的な設定は、デフォルトの /etc/makepkg.conf ファイルの BUILDENVIRONMENT セクションの最後にある BUILDDIR オプションのコメントを外すことで行うことができます。この値をたとえば BUILDDIR=/tmp/makepkg に設定すると、 Arch のデフォルトの /tmp テンポラリ・ファイル・システムが使用されます。

ノート:

• メモリ不足を防ぐために、 tmpfs で大きなパッケージをコンパイルすることは避けてください。
• tmpfs フォルダーは、 noexec オプションなしでマウントする必要があります。そうしないと、ビルドされたバイナリが実行されなくなります。
• tmpfs でコンパイルされたパッケージは、再起動後も保持されないことに注意してください。 PKGDEST オプションを適切に設定して、ビルドされたパッケージを永続ディレクトリに自動的に移動することを検討してください。

ccache

ccache を使うことでコンパイル結果をキャッシュしてビルド時間を短縮できます。

mold linker の使用

mold は、ld/lld リンカーのドロップイン代替品であり、大幅に高速化されていると主張しています。

mold を使用するには、-fuse-ld=mold を LDFLAGS に追加します。例えば:

/etc/makepkg.conf

LDFLAGS="... -fuse-ld=mold"

Rust パッケージに mold を使用するには、-C link-arg=-fuse-ld=mold を RUSTFLAGS に追加します。 例えば:

/etc/makepkg.conf

RUSTFLAGS="... -C link-arg=-fuse-ld=mold"

新しいチェックサムを生成する

PKGBUILD ファイルが存在するディレクトリと同じディレクトリで以下のコマンドを実行すれば新しいチェックサムが生成されます:

$ updpkgsums

Windows の改行コード (\r\n) に注意してください。Git はテキストファイルに含まれている Windows の改行コードを UNIX の改行コード \n に置き換えるため、チェックサムが変わってしまいます。AUR のパッケージのチェックサムが検証できなかった場合、チェックサムを計算する前に以下のコマンドを使ってファイルの中から \r を取り除いてみてください:

$ sed -i 's/\r//g' <filename>

他の圧縮アルゴリズムを使用する

パッケージ アーカイブが大きくなる代わりに、パッケージングとインストールの両方を高速化するには、PKGEXT を変更します。

たとえば、次の例ではパッケージ ファイルの圧縮がスキップされ、インストール で展開する必要がなくなります。

$ PKGEXT='.pkg.tar' makepkg

別の例として、以下は速度に重点を置いた LZ4 アルゴリズムを使用しています。

$ PKGEXT='.pkg.tar.lz4' makepkg

上記の設定を永続化するには /etc/makepkg.conf で PKGEXT を設定します。

マルチコアを利用して圧縮する

zstd は、 --threads フラグを介して 対称型マルチプロセッシング(SMP) をサポートし、圧縮を高速化します。たとえば、 makepkg がパッケージを圧縮するためにできるだけ多くの CPU コアを使用できるようにするには、/etc/makepkg.conf の COMPRESSZST 配列を編集します:

COMPRESSZST=(zstd -c -z -q --threads=0 -)

xz は対称型マルチプロセッシング (SMP) による圧縮をサポートしています。--threads フラグを使うことで圧縮が高速化されます。例えば、makepkg で出来る限り多くの CPU コアを使ってパッケージを圧縮するには、/etc/makepkg.conf の COMPRESSXZ 配列を編集:

COMPRESSXZ=(xz -c -z --threads=0 -)

gzip の代替である並列実装の pigz はデフォルトで全ての CPU コアを使用します (-p/--processes フラグを使うことでコアの数を減らせます。)

COMPRESSGZ=(pigz -c -f -n)

pbzip2は、 bzip2 のドロップイン並列実装であり、デフォルトで使用可能なすべての CPU コアも使用します。 -p# フラグを使用すると、使用するコアの数を減らすことができます(注: -p とコアの数の間にスペースは必要ありません。)

COMPRESSBZ2=(pbzip2 -c -f)

lbzip2 は、デフォルトで利用可能なすべての CPU コアを使用する bzip2 の別のドロップイン並列実装です。-n フラグを使用すると、使用するコアを減らすことができます。

COMPRESSBZ2=(lbzip2 -c -f)

plzip^AUR は lzip のマルチスレッド実装であり、デフォルトで利用可能なすべての CPU コアも使用します。-n/--threads フラグを使用して、使用するコアを減らすことができます。

COMPERSSLZ=(plzip -c -f)

特定のパッケージ作成者によるパッケージを表示

以下のコマンドはシステムにインストールされているパッケージの中から packagername という名前のパッケージ作成者によって作られたパッケージを全て表示します:

$ expac "%n %p" | grep "packagername" | column -t

以下のコマンドは /etc/makepkg の PACKAGER 変数に設定されている値とパッケージ作成者が一致するパッケージを表示します (/etc/pacman.conf に定義されているリポジトリに含まれているパッケージだけが対象):

$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)

64ビット環境で32ビットのパッケージをビルド

警告: この方法で linux パッケージをビルドしようとすると問題が発生するという報告があります。カーネルパッケージをビルドする場合は chroot を使用する方法を使うことを推奨します。

まず multilib リポジトリを有効にして multilib-devel をインストールしてください。gcc や gcc-libs パッケージを削除するかどうかきかれたら yes と答えてください。gcc-multilib は64ビットと32ビット両方のソフトウェアをビルドすることができます。

それから32ビットの設定ファイルを作成:

~/.makepkg.i686.conf

CARCH="i686"
CHOST="i686-unknown-linux-gnu"
CFLAGS="-m32 -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-m32 -Wl,-O1,--sort-common,--as-needed,-z,relro"

そして makepkg を以下のように実行してください:

$ linux32 makepkg --config ~/.makepkg.i686.conf

署名の無いパッケージ

Jenkins などの自動ビルド環境で署名に使用される gpg 秘密鍵のパスフレーズを提供できる人がいない場合があります。パスフレーズなしでシステムに秘密の gpg キーを保存することはお勧めできません。

makepkg で作成された結果の zst パッケージは、作成後に署名することができます。

$ gpg --detach-sign --pinentry-mode loopback --passphrase --passphrase-fd 0 --output NewlyBuilt.pkg.tar.zst.sig --sign NewlyBuilt.pkg.tar.zst 

GPG パスフレーズは、選択したオートメーションスイートによって安全に提供され、隠蔽されます。

出来上がった zst と sig ファイルは有効な署名を期待する pacman クライアントや、あなた自身のリポジトリをホストするときに repo-add --sign で作成したリポジトリから参照することができます。

Magnet URIs

magnet:// のプレフィックスを持つ magnet URIs リソースのサポートは transmission-dlagent^AUR ダウンロードエージェントを使って追加することができます。

トラブルシューティング

QMAKE を使用するパッケージのインストールディレクトリを指定する

qmake によって生成される makefile は INSTALL_ROOT 環境変数を使ってプログラムをインストールするディレクトリを指定します。したがって package 関数を以下のようにしてください:

PKGBUILD

...

package() {
	cd "$srcdir/${pkgname%-git}"
	make INSTALL_ROOT="$pkgdir" install
}

...

また、qmake を正しく設定する必要があります。例えば .pro ファイルに以下を記述してください:

YourProject.pro

...

target.path = /usr/local/bin
INSTALLS += target

...

WARNING: Package contains reference to $srcdir

リテラル文字列 $srcdir か $pkgdir があなたのパッケージ内のインストールされたファイルのどれかに含まれています。

ファイルを確認するには、makepkg のビルドディレクトリから次のコマンドを実行してください:

$ grep -R "$(pwd)/src" pkg/

詳しくは こちら を参照。

プロキシの背後にある時、makepkg は依存関係のダウンロードに失敗します

makepkg が依存関係を呼び出すと、 pacman を呼び出してパッケージをインストールします。これには、 sudo を介した管理者権限が必要です。ただし、 sudoは 環境変数を特権環境に渡さず、プロキシ関連の変数 ftp_proxy、 http_proxy、 https_proxy、 および no_proxy

プロキシの背後で makepkg を機能させるには、次のいずれかの方法を実行する必要があります。

XferCommand で URL を設定して、プロキシを有効にする

XferCommandは、 /etc/pacman.conf で目的のプロキシURLを使用するように設定できます。 pacman.conf [5] に次の行を追加するか、コメントを解除します。

/etc/pacman.conf

...
XferCommand = /usr/bin/curl -x http://username:password@proxy.proxyhost.com:80 -L -C - -f -o %o %u
...

sudoer の env_keep を介してプロキシを有効にする

あるいは、sudoer の env_keep オプションを使用することもできます。これにより、特定の変数を特権環境に保持できます。詳細については、 sudo#環境変数 を参照してください。

makepkg は失敗するが、make は成功する

make を使用して手動でコンパイル出来ても、makepkg で失敗する場合、それはほぼ確実に /etc/makepkg.conf がコンパイル変数を通常は機能する合理的なものに設定されていますが、それは コンパイルしているものと互換性がありません。 これらのフラグを PKGBUILD options 配列に追加してみてください。

!buildflags、 デフォルトの CPPFLAGS、 CFLAGS、 CXXFLAGS、 および LDFLAGS を防ぐため。

!makeflags、 並列ビルドを有効にするために /etc/makepkg.conf を編集した場合に、デフォルトの MAKEFLAGS を防ぐため。

!debug、 デフォルトの DEBUG_CFLAGS を防ぐため、および DEBUG_CXXFLAGS (パッケージがデバッグビルドの場合)

これらのいずれかで問題が修正された場合、問題の原因となっているフラグを正確に特定すれば、アップストリームでバグを報告できる可能性があります。

システムが使用できないほど遅くなる

systemd コントロールグループでの makepkg の実行

ビルドしているパッケージが、デフォルトの make フラグ (他のほとんどのパッケージでは適切に設定されている) を使用してビルドするには多くのリソースを必要とします、そのパッケージを独自の コントロールグループ で実行してみて下さい。makepkg-cg^AUR は、systemd コントロール グループを介してこれを実現する makepkg のラッパーです (systemd.resource-control(5) を参照)

参照

• makepkg(8) マニュアルページ
• makepkg.conf(5) マニュアルページ
• gcccpuopt: 現在の CPU にあわせた gcc の cpu オプションを表示するスクリプト
• makepkg のソースコード