makepkg

関連記事

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

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

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

設定

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

/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 でビルドされます)。

署名チェック

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

.sig や .asc 形式の署名ファイルが PKGBUILD の source 行に含まれている場合、makepkg は自動的に署名を検証します。ユーザーのキーリングに署名検証に必要な公開鍵が存在しない場合、makepkg はインストールを停止して PGP 鍵が検証できないというメッセージを表示します。

PKGBUILD に validpgpkeys エントリで鍵 ID が指定されているときパッケージをビルドするには公開鍵が必要になります。公開鍵が存在しない場合、あるいは他の開発者による公開鍵を追加したい場合、手動で鍵をインポートするか、もしくは鍵サーバーを使ってインポートすることができます。

使用方法

次に進む前に、base-devel グループがインストールされているか確認してください。このグループに属しているパッケージは PKGBUILD の中に依存パッケージとして載せる必要はないことになっています。以下を (root で) 実行して base-devel グループをインストールしてください:

# pacman -S base-devel

ノート: 依存パッケージが欠けていることに不満を言う前に、全ての Arch Linux 環境では base グループがインストールされていることが前提になっていることを思い出してください。makepkg や AUR ヘルパーでビルドするときには base-devel グループがインストールされていることが前提になっています。

パッケージを作成するには、まずパッケージの作成に記述されているようにして PKGBUILD を作成するか ABS ツリーや Arch User Repository などから取得してくる必要があります。

警告: 信頼できるソースからパッケージをビルド・インストールしてください。

PKGBUILD を入手したら、PKGBUILD が保存されているディレクトリに移動してから次のコマンドを実行して PKGBUILD に記述されたパッケージを作成します:

$ makepkg

パッケージ作成後、要らなくなったファイル ($srcdir に展開されたファイルなど) を makepkg によって削除するには、以下のオプションを加えて下さい。同じパッケージをビルドしたりパッケージのバージョンを更新するときに、同じビルドフォルダを使う場合、このオプションは有益です。残ったファイルを新しいビルドに持ち越す危険がなくなります。

$ makepkg -c

必要な依存パッケージが欠けている場合、makepkg は警告を表示します。必要な依存パッケージを自動的にインストールするには、次のコマンドを使って下さい:

$ makepkg -s

依存パッケージが取ってこれるのは設定されたリポジトリからだけということに注意してください; 詳しくは pacman#リポジトリ を見て下さい。また、ビルドの前に手動で依存パッケージをインストールすることもできます (pacman -S --asdeps dep1 dep2)。

全ての依存関係が解決されパッケージのビルドが成功すれば、パッケージファイル (pkgname-pkgver.pkg.tar.xz) が作業ディレクトリの中に作成されます。インストールするには、(root で) 次を実行してください:

# pacman -U pkgname-pkgver.pkg.tar.xz

もしくは、pacman -U pkgname-pkgver.pkg.tar.xz を実行する代わりに -i フラグを使ってインストールすることもできます:

$ makepkg -i

Tips and tricks

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

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 は期待通りに機能しなくなります [2]。どのオプションが実際に有効になるのかはコンパイルを行わないと分かりません。詳しくは Gentoo wiki の Find CPU-specific options を参照。
• gcccpuopt スクリプトを使うことで 32ビットの x86 アーキテクチャの最適化オプションを確認することができます。

MAKEFLAGS

MAKEFLAGS オプションを使って make に追加するオプションを指定することができます。マルチコア・マルチプロセッサのシステムを使っているユーザーは同時に実行するジョブの数を指定できます、例: -j4。nproc を使うことで利用可能なプロセッサの数がわかります。PKGBUILD によっては、特定のバージョンで競合状態になったり、もしくはマルチコアによるコンパイルがサポートされていないために、この値を -j1 で上書きします。これによってビルドが失敗するパッケージがある場合は、エラーがあなたの MAKEFLAGS によって引き起こされていることを確認してから、バグトラッカーに報告してください。

利用可能なオプションの全ては man make を見て下さい。

パッケージの堅牢化

hardening-wrapper パッケージをインストールしてください。このパッケージは gcc や g++ などをラッピングして /etc/hardening-wrapper.conf でセキュリティを強化するフラグを制御できます。

ハードニングフラグを全て有効にするには:

/etc/hardening-wrapper.conf

HARDENING_BINDNOW=1
HARDENING_PIE=1
HARDENING_FORTIFY=2
HARDENING_RELRO=1
HARDENING_STACK_CHECK=1
HARDENING_STACK_PROTECTOR=2

インストール後、/etc/profile を source するか、一度ログアウトしてログインしなおす必要があります。ラッパーが使われているか確認するには:

$ which gcc
/usr/lib/hardening-wrapper/bin/gcc

後は普通にパッケージを作成すれば自動的に使用されます。

セキュリティを高めるフラグが使われているかどうか確認したい場合、checksec パッケージをインストールしてください。個別の実行ファイルをチェックしたり、ディレクトリを再帰的にチェックできます。例:

$ checksec --dir /tmp/makepkg/dwm/pkg/dwm/usr/bin
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FORTIFY Checked         Total   Filename
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   Yes     4               6       /tmp/makepkg/dwm/pkg/dwm/usr/bin/dwm

セキュリティ#パッケージの再ビルドも参照してください。

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

以下のコマンドはシステムにインストールされているパッケージの中から 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)

コンパイル時間を短縮する

tmpfs

パッケージをコンパイルするのは I/O に負担がかかる作業のため、tmpfs を利用することでビルド時間を大幅に短縮することができます。該当する /etc/makepkg.conf のオプションは BUILD ENVIRONMENT セクションの一番下にあります:

/etc/makepkg.conf

[...]

#########################################################################
# BUILD ENVIRONMENT
#########################################################################
#
# Defaults: BUILDENV=(!distcc color !ccache check !sign)
#  A negated environment option will do the opposite of the comments below.
#
#-- distcc:   Use the Distributed C/C++/ObjC compiler
#-- color:    Colorize output messages
#-- ccache:   Use ccache to cache compilation
#-- check:    Run the check() function if present in the PKGBUILD
#-- sign:     Generate PGP signature file
#
BUILDENV=(!distcc color !ccache check !sign)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""
#
#-- Specify a directory for package building.
#BUILDDIR=/tmp/makepkg

[...]

BUILDDIR=/tmp/makepkg 行をアンコメントして BUILDDIR=/tmp/builds などに設定すれば (もしくはデフォルトの値のままにすれば) Arch のデフォルトの /tmp tmpfs が使用されます。

ノート: tmpfs フォルダは noexec オプションを付けずにマウントされている必要があります。このオプションを使うとビルドスクリプトやユーティリティが実行できません。また、tmpfs の記事に記されているように、デフォルトのサイズは利用できる RAM の半分となっており、容量を全て使いきってしまうおそれがあります。

tmpfs でコンパイルしたパッケージは再起動するとなくなってしまうので注意してください。そのため、何度もインストールするようなパッケージは他の（永続的な）ディレクトリに移動したほうが良いでしょう。

ccache

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

Generate new checksums

Run the following command in the same directory as the PKGBUILD file to generate new checksums:

$ updpkgsums

Beware of Windows-style newlines (\r\n). Git replaces those with UNIX-style \n newlines in text files, which causes a difference in checksum. If checksum verification fails for your package on the AUR, try stripping the \rs from each file with

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

before calculating the checksums.

Use other compression algorithms

To speed up both packaging and installation, with the tradeoff of having larger package archives, you can change PKGEXT. For example, the following makes the package archive uncompressed for only one invocation:

$ PKGEXT='.pkg.tar' makepkg

As another example, the following uses the lzop algorithm, with the lzo package required:

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

To make one of these settings permanent, set PKGEXT in /etc/makepkg.conf.

Utilizing multiple cores on compression

xz supports symmetric multiprocessing (SMP) via the --threads flag to speed up compression. For example, to let makepkg use as many CPU cores as possible to compress packages, edit COMPRESSXZ array in /etc/makepkg.conf:

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

pigz is a drop-in, parallel implementation for gzip which by default uses all available CPU cores (the -p/--processes flag can be used to employ less cores):

COMPRESSGZ=(pigz -c -f -n)

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

トラブルシューティング

Makepkg によるパッケージの署名に失敗する

gnupg 2.1 から gpg-agent は手動で起動する必要がなくなり、gpg を実行したときに自動的に起動します。gpg-agent を手動で起動しなかったとき makepkg によって起動されます。問題は makepkg が fakeroot で gpg を起動するため、gpg-agent も同じ環境で起動されてしまいます。これによって問題が起こります。makepkg を実行する前に手動で gpg-agent を起動することで解決できますが (詳しくは GnuPG#gpg-agent を参照)、信頼性のある方法ではありません: FS#49946。

gpg-agent の設定に頭を使いたくない場合、署名は後回しにして makepkg を実行し、それから gpg --detach-sign name.pkg.tar.xz でパッケージに署名する方法もあります。

QMAKE を使用するパッケージで makepkg.conf の CFLAGS/CXXFLAGS/CPPFLAGS が適用されない

Qmake は CFLAGS と CXXFLAGS 変数を自動的に設定します。makepkg の設定ファイルで定義した変数を qmake に使わせるには、PKGBUILD を編集して QMAKE_CFLAGS_RELEASE と QMAKE_CXXFLAGS_RELEASE 変数を qmake に指定する必要があります。例:

PKGBUILD

...

build() {
  cd "$srcdir/$_pkgname-$pkgver-src"
  qmake-qt4 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \
    PREFIX=/usr \
    QMAKE_CFLAGS_RELEASE="${CFLAGS}"\
    QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"

  make
}

...

もしくは、システム全体で設定したい場合、qmake.conf を作成して QMAKESPEC 環境変数を設定してください。

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