PKGBUILD
関連記事
PKGBUILD はパッケージを作成するときに使われる Arch Linux のパッケージビルド記述ファイルです (中身はシェルスクリプトです)。
Arch Linux では makepkg ユーティリティと PKGBUILD 内の情報を使ってパッケージがビルドされます。makepkg が実行されると、作業ディレクトリ内で PKGBUILD
が検索されその中の記述に従ってコンパイルしたりファイルを取得してパッケージファイル (pkgname.pkg.tar.xz
) が作成されます。作られたパッケージにはバイナリファイルとインストールの記述が含まれており、pacman によって読み込まれインストールされます。
この記事では PKGBUILD で使用する変数について扱っています。PKGBUILD の関数についての情報は、パッケージの作成#PKGBUILD の関数を参照してください。
変数
PKGBUILD ファイルの中で使うことができる変数は以下の通りです。
pkgname
, pkgver
, pkgrel
, arch
は全て必須です。license
はパッケージのビルドには必須ではありませんが、他の人と共有したい PKGBUILD には含めるのが推奨されています。存在しない場合 makepkg
は警告を表示します。
PKGBUILD 内では変数をこのページと同じ順番で定義するのが通例となっています。ただし、それは必須ではなく、Bash の構文が正しければ問題ありません。
パッケージ名
pkgbase
分割パッケージを作成するときに使うことができる、任意のグローバルディレクティブ。pkgbase
を使うことで makepkg の出力とソース tarball の名でパッケージのグループを参照することができます。pkgbase が指定されていない場合、pkgname
変数の最初のエレメントが使われます。この変数の先頭の文字をハイフンにすることはできません。分割パッケージの全ての値はデフォルトで PKGBUILD に指定されたグローバルな値になります。#makedepends, #ソース, #整合性 の変数を除く、全ての変数を分割パッケージの package()
関数で上書きすることができます。
pkgname
パッケージの名前。含めることができる文字は、小文字の英数字と以下の記号です: @
, .
, _
, +
, -
(アットマーク、ドット、アンダーバー、プラス、ハイフン)。全ての文字は小文字でなくてはならず名前の最初をハイフンにすることはできません。一貫性を保つために、pkgname
はパッケージするソース tarball の名前と一致させてください。例えば、ソフトウェアが foobar-2.5.tar.gz
なら、pkgname
の値は foobar
にするべきです。PKGBUILD ファイルを入れる作業ディレクトリも pkgname
と一致させる必要があります。
分割パッケージは配列として定義します。例: pkgname=('foo' 'bar')
。
バージョン
pkgver
パッケージのバージョン。この値はパッケージの作成者によって公開されたバージョンと同じでなくてはなりません。文字と数字、ピリオドとアンダーバーを使えますがハイフンは使うことができません。パッケージの作成者がバージョンのナンバリングにハイフンを使っている時は、アンダーバーに置き換えてください。例えば、バージョンが 0.99-10 の場合、0.99_10 に変更してください。pkgver
を後で PKGBUILD で使うときに、ダッシュの代わりにアンダーラインを使うのは簡単にできます 例:
source=($pkgname-${pkgver//_/-}.tar.gz)
pkgrel
Arch Linux におけるパッケージのリリース番号。パッケージの同じバージョンを続けてビルドするときにそれを区別するためにこの値を使います。新しいバージョンのパッケージが始めてリリースされたとき、リリース番号は1からスタートします。PKGBUILD
ファイルに修正や最適化が加えられるたびに、パッケージは再リリースされリリース番号は1づつ増やされます。新しいバージョンのパッケージが出たら、リリース番号は1にリセットします。
epoch
バージョン番号が更新を引き起こさないときでも、(epoch が低い) 以前のバージョンよりもパッケージを新しいものだと強制的に見せるために使用されます。この変数の値は正の整数でなくてはなりません。指定されていない場合、デフォルトの値は 0 になります。パッケージのナンバリングの規則が変更されたり、バージョンの通常の比較ルールを破壊したいときに有用です。例:
pkgver=5.13 pkgrel=2 epoch=1
1:5.13-2
バージョンの比較についての詳細は pacman(8) を見て下さい。
汎用
pkgdesc
パッケージの説明。説明は80文字以下でなくてはならず、また説明の中にパッケージ名を含めて自己参照してはいけません。例えば、"Nedit is a text editor for X11" は "A text editor for X11" に書き換えてください。
arch
PKGBUILD
がビルド・動作するアーキテクチャの文字列。現在、i686
と x86_64
が使えます。ただし、Arch Linux ARM などのプロジェクトでは他のアーキテクチャもサポートしています: arm
(armv5), armv6h
(armv6 hardfloat), armv7h
(armv7 hardfloat), aarch64
(armv8 64bit)。
アーキテクチャに依存しないパッケージ (シェルスクリプト, フォント, テーマなど) には any
を使うことができます。-i686
や -x86_64
とは対照的に、一度ビルドしたら他のアーキテクチャでも使うことができるようなパッケージには -any
を指定してください。全てのアーキテクチャに対応するようにパッケージをコンパイルすることができても、特定のアーキテクチャに向けてコンパイルされる場合は、Arch によって公式にサポートされているアーキテクチャを指定してください: arch=('i686' 'x86_64')
。
$CARCH
変数を使うことで、ビルドや、変数を定義する時にターゲットとするアーキテクチャを知ることができます。FS#16352 を参照してください。例:
depends=(foobar) if test "$CARCH" == x86_64; then depends+=(lib32-glibc) fi
url
パッケージされるソフトウェアの公式サイトの URL。
license
ソフトウェアが配布されるライセンス。[core]
の licenses パッケージは /usr/share/licenses/common
によく使われるライセンスを保存しています、例えば /usr/share/licenses/common/GPL
。パッケージのライセンスがここに保存されているライセンスのどれかのときは、ディレクトリの名前を設定してください、例えば license=('GPL')
。適切なライセンスが公式の licenses パッケージに含まれていない場合は、やる必要があることがいくつかあります:
- ライセンスファイルを次のディレクトリに含めなくてはなりません:
/usr/share/licenses/pkgname/
, 例/usr/share/licenses/foobar/LICENSE
。 - ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。
license
行にcustom
を追加してください。任意で、custom
をcustom:ライセンスの名前
にすることができます。あるライセンスが ([community] を含む
) 公式リポジトリの2つ以上のパッケージで使われると、licenses パッケージに入れられます。
- 特別な事例として BSD, MIT, zlib/png, Python ライセンスは licenses パッケージに含められていません。
license
行の目的のために、一般的なライセンス (license=('BSD')
,license=('MIT')
,license=('ZLIB')
,license=('Python')
) として扱われておきながらそれぞれ固有の copyright 行を持っているために技術的にカスタムライセンスになっています。これら4つのライセンスを使っている全てのパッケージは/usr/share/licenses/pkgname
内にそのライセンスを保存しておく必要があります。パッケージによってはライセンスがひとつだけではないこともあります。そのような場合は、license 行に複数のエントリを書くことができます、例えばlicense=('GPL' 'custom:name of license')
。 - さらに、(L)GPL には多くのバージョンと組み合わせが存在します。(L)GPL ソフトウェアで使えるのは:
- (L)GPL - (L)GPLv2 とそれ以降のバージョン
- (L)GPL2 - (L)GPL2 のみ
- (L)GPL3 - (L)GPL3 とそれ以降のバージョン
- license が決められていないと、
PKGBUILD.proto
はunknown
を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。
groups
パッケージが属するグループ。例えば、kdebase パッケージをインストールすると、kde グループに含まれる全てのパッケージをインストールします。
依存関係
depends
ソフトウェアを実行する前にインストールする必要があるパッケージの名前を示す文字列。ソフトウェアが依存パッケージの最低必要バージョンがあるときは、>=
演算子を使ってこれを表して下さい、例 depends=('foobar>=1.8.0')
。あなたのソフトウェアが依存している他のパッケージの依存にすでに含まれているパッケージを depends に加える必要はありません。例えば、gtk2 は glib2 と glibc に依存しています。しかしながら、glibc は glib2 の依存にあるので gtk2 の依存として glibc を含める必要はありません。
optdepends
ソフトウェアを機能させるのには必要ないが機能を追加することができるパッケージの名前の文字列。それぞれのパッケージが提供する機能の説明も短く書いておいて下さい。例えば optdepends
は以下のようになります:
optdepends=('cups: printing support' 'sane: scanners support' 'libgphoto2: digital cameras support' 'alsa-lib: sound support' 'giflib: GIF images support' 'libjpeg: JPEG images support' 'libpng: PNG images support')
makedepends
ソフトウェアをビルドするためにインストールする必要はあるが、インストール後にソフトウェアを使うために残しておく必要はないパッケージの名前。depends
行と同じフォーマットを使ってパッケージの最小必要バージョンを指定できます。
checkdepends
テストスイートを実行するときに必要だが普通の実行時には必要ないパッケージの文字列。このリストのパッケージは depends と同じフォーマットに従います。check() 関数が makepkg によって実行される時だけこの依存関係が考慮されます。
パッケージの関係性
provides
パッケージの機能を提供するパッケージ (もしくは cron
や sh
などの仮想パッケージ) の名前の文字列。同じものを提供するパッケージは互いに衝突しないかぎり同時にインストールすることができます(下を見て下さい)。この変数を使う場合は、バージョンによって影響を受ける依存関係がある場合パッケージが提供するバージョン (pkgver
と恐らく pkgrel
) を追加してください。例えば、qt にモディファイを加えて qt を提供する qt-foobar バージョン 3.3.8 という名前で作成するときは、provides
行は provides=('qt=3.3.8')
のようにしてください。provides=('qt')
とすると qt の特定バージョンを必要とする依存関係が破壊されることになります。provides
行に pkgname
を加えないでください、自動で追加されます。
conflicts
インストールするとパッケージと問題が生じるパッケージの名前の文字列。この名前を持つパッケージとこの名前の仮想パッケージを provides
に入れている全てのパッケージが削除されます。depends
行と同じフォーマットを使って衝突するパッケージのバージョンプロパティを指定することもできます。
replaces
パッケージによって置き換えられる廃止パッケージの名前の文字列、例えば wireshark パッケージには replaces=('ethereal')
。pacman -Sy
で同期をした後、リポジトリ内の replaces
に一致する他のパッケージが現れるとインストールされたパッケージを置き換えます。既存のパッケージの別バージョンを提供するときは、衝突するパッケージをインストールするときに評価される conflicts
変数を使って下さい。
その他
backup
ユーザーが作成した変更を含んだり、パッケージのアップグレードや削除が行われても維持されるファイルの文字列、主に /etc
内の設定ファイル用。
アップデート時、既存のファイル(ユーザーによって修正されたファイル)を上書きしないために新しいバージョンは file.pacnew
として保存されます。同じく、パッケージの削除時、パッケージを削除するのに pacman -Rn
コマンドを使わなければ、ユーザーが修正したファイルは file.pacsave
として残されます。
この行のファイルパスは絶対パス (例: /etc/pacman.conf
) ではなく相対パス (例: etc/pacman.conf
) にしてください。Pacnew と Pacsave ファイルも参照。
options
この文字列を使うと /etc/makepkg.conf
で定義された makepkg
のデフォルトの挙動の一部を上書きできます。オプションをセットするには、文字列にオプションの名前を入れて下さい。デフォルトの挙動を逆にするには、オプションの前に !
を付けて下さい。options には以下のオプションを置くことが可能です:
strip
- バイナリとライブラリからシンボルを除去。プログラムやライブラリでデバッガを頻繁に使う時は、このオプションを無効にすると便利です。docs
-/doc
ディレクトリを保存。libtool
- パッケージに libtool (.la
) ファイルを残す。staticlibs
- パッケージに静的ライブラリ (.a) のファイルを残す。emptydirs
- パッケージに空のディレクトリを残す。zipman
- man と info ページを gzip で圧縮。purge
- パッケージのPURGE_TARGETS
変数で指定されたファイルを削除。upx
- UPX を使って実行可能バイナリを圧縮。UPXFLAGS
変数を指定することで UPX に追加オプションを渡せます。ccache
- ビルド中のccache
の使用を許可。ccache
を使ってビルドすると問題が起こるパッケージに無効化の!ccache
を使うと便利です。distcc
- ビルド中のdistcc
の使用を許可。distcc
を使ってビルドすると問題が起こるパッケージに無効化の!distcc
を使うと便利です。buildflags
- ビルド中にユーザー定義のbuildflags
(CFLAGS, CXXFLAGS, LDFLAGS) の使用を許可。カスタムしたbuildflags
を使ってビルドすると問題が起こるパッケージに無効化の!buildflags
を使うと便利です。makeflags
- ビルド中にユーザー定義のmakeflags
の使用を許可。カスタムしたmakeflags
を使ってビルドすると問題が起こるパッケージに無効化の!makeflags
を使うと便利です。
install
パッケージに含まれる .install
スクリプトの名前。pkgname
と同じ名前にしてください。パッケージのインストール・削除・アップグレードの際に、pacman はパッケージごとにスクリプトを保存・実行する機能があります。スクリプトには、実行される段階によって以下の関数を含めることができます:
pre_install
- ファイルが展開される前にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。post_install
- ファイルが展開された後にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。pre_upgrade
- ファイルが展開される前にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。post_upgrade
- ファイルが展開された後にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。pre_remove
- ファイルが削除される前にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。post_remove
- ファイルが削除された後にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。
それぞれの関数は pacman のインストールディレクトリの中に chroot されて実行されます。このスレッド を見て下さい。
changelog
パッケージの変更履歴の名前。インストールされたパッケージの変更履歴を表示するには:
$ pacman -Qc pkgname
ソース
source
パッケージをビルドするのに必要なファイルの文字列。ソフトウェアのソースの場所を入れる必要があり、多くの場合 HTTP や FTP の URL です。前に設定した pkgname
や pkgver
変数をここで使うことができます (例: source=(http://example.com/$pkgname-$pkgver.tar.gz)
)。
自作のパッチなど、オンザフライでダウンロードできないファイルを供給する必要があるときは、PKGBUILD
ファイルがあるところと同じディレクトリにそのファイルを入れて source にファイル名を追加するだけです。ここに追加したパスはすべて PKGBUILD
があるディレクトリから相対的に考えられます。本当のビルドプロセスが始まる前に、この行で参照されている全てのファイルがダウンロードされるか存在を確認します。もしファイルが欠けている場合は makepkg
は次に進みません。
拡張子が .sig, .sign, .asc のファイルを source 配列に指定した場合、makepkg はそれを PGP 署名として認識して、ソースファイルの整合性を確認するのに自動的に用います。
noextract
source
行で makepkg
によって圧縮フォーマットを展開してはいけないファイルの文字列。libarchive は unzip とは違い全てのファイルをランダムアクセスではなくストリームで処理するので、/usr/bin/bsdtar
によって扱えない圧縮ファイルに noextract を使うのがほとんどです。こういった場合には他の解凍ツール (例: unzip
, p7zip
など) を makedepends
に追加して prepare() 関数の最初の行でソースの圧縮ファイルを手動で展開する必要があります。例えば:
prepare() { lrzip -d source.tar.lrz }
source
行には URL を指定することが可能ですが、noextract
にはファイル名の一部だけを指定します。例えば、以下のようにすることができます (grub2 の PKGBUILD から引用):
source=("http://ftp.archlinux.org/other/grub2/grub2_extras_lua_r20.tar.xz") noextract=("grub2_extras_lua_r20.tar.xz")
何も展開しないようにするには、以下のように工夫してください (firefox-i18n から引用):
noextract=(${source[@]%%::*})
整合性
md5sums
source
行に含まれるファイルの MD5 チェックサムの文字列。source
行の全てのファイルが利用できるようになると、それぞれのファイルの MD5 ハッシュが自動で生成され source
行と同じ順番で md5sums の値と比較されます。ソースファイルの順番自体に意味はありませんが、makepkg
はどのチェックサムがどのソースファイルにあたるか考慮しないので md5sums の順番が一致していることは重要です。PKGBUILD
ファイルが含まれているディレクトリで updpkgsums
や makepkg -g
コマンドを使うことで簡単に素早くこの行を生成することができます。
sha1sums
SHA-1 160-bit チェックサムの文字列。上述の md5sums
の代わりになるものですが、これにも脆弱性があることが知られています、より強固なアルゴリズムを使うことも考えるべきでしょう。このチェックサムの使用・生成を有効にするには、/etc/makepkg.conf
に INTEGRITY_CHECK
オプションを設定してください。man makepkg.conf
を参照。
sha256sums, sha384sums, sha512sums
それぞれ 256, 384, 512 ビットのダイジェストサイズの SHA-2 チェックサムの文字列。上述の md5sums
の代わりになるもので一般的にはより強固だと考えられています。このチェックサムの使用・生成を有効にするには、/etc/makepkg.conf
に INTEGRITY_CHECK
オプションを設定してください。man makepkg.conf
を参照。