PKGBUILD

関連記事

• Arch パッケージングスタンダード
• Arch Build System
• パッケージの作成
• .SRCINFO
• カテゴリ:パッケージ開発
• カスタムローカルリポジトリ
• pacman ヒント
• Arch User Repository
• makepkg
• pacman

この記事では PKGBUILD の中でメンテナが定義できる変数について説明します。PKGBUILD の関数や一般的なパッケージの作成については パッケージの作成 を参照してください。PKGBUILD(5) も読んで下さい。

PKGBUILD はシェルスクリプトで、Arch Linux のパッケージが必要とするビルド情報を含んでいます。

Arch Linux のパッケージは makepkg ユーティリティを使ってビルドされます。makepkg を実行すると、カレントディレクトリにある PKGBUILD ファイルを探し、その中の指示に従ってコンパイルするか、パッケージアーカイブ (pkgname.pkg.tar.zst) を構築するためのファイルを入手します。出来上がったパッケージにはバイナリファイルとインストール手順が含まれ、pacman で簡単にインストールできます。

必須の変数は、pkgname、pkgver、pkgrel、および arch です。 license は、パッケージをビルドするために厳密に必要というわけではありませんが、makepkg が存在しない場合に警告を生成するため、他のユーザーと共有する PKGBUILD には推奨されます。

ここで指定された順番で PKGBUILD の変数を定義するのが一般的なやり方です。しかし、正しい Bash 構文が使われている限り、これは必須ではありません。

ヒント: PKGBUILD によくあるパッケージングの間違いがないかチェックするには namcap を使って下さい。

パッケージ名

pkgbase

通常のパッケージをビルドするときは、この変数を PKGBUILD で明示的に宣言してはいけません: この変数のデフォルトの値は pkgname の値です。

分割パッケージ をビルドするときは、この変数を使って makepkg の出力やソースだけの tarball の名前付けにパッケージのグループを参照するために使う名前を明示的に指定できます。この値はハイフンで始めることはできません。指定しない場合、値はデフォルトで pkgname 配列の最初の要素になります。

分割パッケージのすべてのオプションとディレクティブのデフォルトは PKGBUILD で指定されたグローバルな値です。ただし、以下のものは各分割パッケージのパッケージング関数の中でオーバーライドすることができます。pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install そして changelog

pkgname

パッケージの名前、例えば pkgname='foo' か、分割パッケージの場合は名前の配列、例えば pkgname=('foo' 'bar') を指定します。パッケージ名は小文字の英数字と以下の文字のみで構成されている必要があります。@._+- は小文字の英数字と以下の文字で構成されています。(アットマーク、ドット、アンダースコア、プラス、ハイフン) ハイフンやドットで名前を始めることはできません。一貫性を保つために、pkgname はソフトウェアのソース tarball の名前と一致させるべきです。例えば、ソフトウェアが foobar-2.5.tar.gz に入っているならば、pkgname=foobar と記述して下さい。

バージョン

pkgver

パッケージのバージョン。この値はパッケージの作成者によって公開されたバージョンと同じでなくてはなりません。文字と数字、ピリオドとアンダーバーを使えますがハイフンは使うことができません。パッケージの作成者がバージョンのナンバリングにハイフンを使っている時は、アンダーバーに置き換えてください。例えば、バージョンが 0.99-10 の場合、0.99_10 に変更してください。pkgver を後で PKGBUILD で使うときに、ダッシュの代わりにアンダーラインを使うのは簡単にできます 例:

source=($pkgname-${pkgver//_/-}.tar.gz)

ノート: ソフトウェアの開発元が 30102014 のようなタイムスタンプによるバージョン付けをしている場合、日付の順序を逆にしてください: 20141030 (ISO 8601 形式)。そうしないと新しいバージョンが認識されません。

ヒント:

• pacman パッケージに含まれている vercmp を使うことでバージョンの優先度をテストできます。
• PKGBUILD に pkgver() 関数を定義することで makepkg は自動的に pkgver 変数を 更新 します。詳しくは VCS パッケージガイドライン#関数 pkgver() を見て下さい。

pkgrel

Arch Linux におけるパッケージのリリース番号。パッケージの同じバージョンを続けてビルドするときにそれを区別するためにこの値を使います。新しいバージョンのパッケージが始めてリリースされたとき、リリース番号は1からスタートします。PKGBUILD ファイルに修正や最適化が加えられるたびに、パッケージは再リリースされリリース番号は1づつ増やされます。新しいバージョンのパッケージが出たら、リリース番号は1にリセットします。

epoch

警告: epoch はどうしても必要なときだけ使って下さい。

バージョン番号が更新を引き起こさないときでも、(epoch が低い) 以前のバージョンよりもパッケージを新しいものだと強制的に見せるために使用されます。この変数の値は正の整数でなくてはなりません。指定されていない場合、デフォルトの値は 0 になります。パッケージのナンバリングの規則が変更されたり、バージョンの通常の比較ルールを破壊したいときに有用です。例:

pkgver=5.13
pkgrel=2
epoch=1

1:5.13-2

バージョンの比較についての詳細は pacman(8) を見て下さい。

汎用

pkgdesc

パッケージの説明。これは 80 文字以下にすることをお勧めします。また、アプリケーション名がパッケージ名と異なる場合を除き、パッケージ名を自己参照的に含めないでください。たとえば、pkgdesc="Nedit is a text editor for X11" の代わりに pkgdesc="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 パッケージに含まれていない場合は、やる必要があることがいくつかあります:

1. ライセンスファイルを次のディレクトリに含めなくてはなりません: /usr/share/licenses/pkgname/, 例 /usr/share/licenses/foobar/LICENSE
2. ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。
3. 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 を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。

ヒント: ソフトウェアの作者によってはライセンスファイルを作らずに普通の ReadMe.txt の中に配布ルールについて記述しているかもしれません。build() フェイズの時に、次のようにすることでファイルにこの情報を展開することが可能です: sed -n '/This software/,/ thereof./p' ReadMe.txt > LICENSE

こちらも参照 ノンフリーアプリケーションパッケージガイドライン

フリーおよびオープン ソース ソフトウェア ライセンスに関する追加情報と展望は、次のページで見つけることができます。

• 自由ソフトウェアライセンス
• Wikipedia:Comparison of free and open-source software licenses
• オープン ソースおよびフリー ソフトウェア プロジェクトの法的問題の入門書
• GNU Project - さまざまなライセンスとそれらについての解説
• Debian - ライセンス情報
• Open Source Initiative - 名前別ライセンス

groups

パッケージが属する group たとえば、plasma をインストールすると、そのグループに属するすべてのパッケージがインストールされます。

依存関係

ノート: アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけの依存パッケージを追加することができます。例: depends_x86_64=(), optdepends_x86_64=()。

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 行と同じフォーマットを使ってパッケージの最小必要バージョンを指定できます。

ノート: 既に depends に含まれているパッケージを指定する必要はありません。

警告: makepkg でビルドする際 base-devel グループは既にインストールされているものと前提されます。"base-devel" のパッケージを makedepends 行に入れてはいけません。

checkdepends

テストスイートを実行するときに必要だが普通の実行時には必要ないパッケージの文字列。このリストのパッケージは depends と同じフォーマットに従います。check() 関数が makepkg によって実行される時だけこの依存関係が考慮されます。

パッケージの関係性

ノート: アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけのパッケージの関係性を追加することができます。例: provides_x86_64=(), conflicts_x86_64=()

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 行と同じフォーマットを使って衝突するパッケージのバージョンプロパティを指定することもできます。

競合は、pkgname および provides 配列で指定された名前に対してチェックされることに注意してください。したがって、パッケージが provides に foo 機能を備えている場合、conflicts 配列に foo を指定すると、あなたのパッケージと、provides 配列に foo を含む他のすべてのパッケージとの間の競合 (つまり、競合するすべてのパッケージ名を flicts 配列に指定する必要はありません) 具体的な例を挙げてみましょう。

• netbeans は暗黙的に netbeans を pkgname 自身として提供しています。
• netbeans-cpp^AUR は netbeans を提供し、netbeans と衝突します。
• netbeans-php^AUR は netbeans を提供し、netbeans と衝突しますが、同じ機能を提供するパッケージは暗黙のうちに衝突するので、明示的に netbeans-cpp^AUR と衝突する必要はありません。

パッケージが provides 配列を介して同じ機能を提供する場合、代替パッケージを conflicts 配列に明示的に追加する場合と追加しない場合には違いがあります。conflicts 配列が明示的に宣言されている場合、同じ機能を提供する 2 つのパッケージが 代替 とみなされます。conflicts 配列が欠落している場合、同じ機能を提供する 2 つのパッケージが 共存している可能性がある とみなされます。パッケージャは、conflicts 変数を宣言するかどうかを決定する際に、provides 変数の内容を常に無視する必要があります。

replaces

例えば wireshark-qt は replaces=('wireshark') を使います。同期する時、pacman はインストールされたパッケージがリポジトリで replaces にマッチする別のパッケージに出会ったら即座に置き換えます。既にあるパッケージの別バージョンを提供したり AUR にアップロードする時は conflicts と provides 配列を使ってください。

その他

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 されて実行されます。このスレッド を見て下さい。

ヒント: .install のプロトタイプが /usr/share/pacman/proto.install にあります。

ノート: スクリプトの中で exit を実行しないでください。スクリプト内の関数が実行できなくなってしまいます。

changelog

パッケージの変更履歴の名前。インストールされたパッケージの変更履歴を表示するには:

$ pacman -Qc pkgname

ヒント: 変更履歴ファイルのプロトタイプが /usr/share/pacman/ChangeLog.proto にあります。

ソース

ノート: アンダーバーとアーキテクチャの名前を追加することで特定のアーキテクチャのソースを追加することができます。例: source_x86_64=()。そのアーキテクチャのソースと対応するチェックサムも指定してください。例: sha256sums_x86_64=()。

source

パッケージをビルドするのに必要なファイルの文字列。ソフトウェアのソースの場所を入れる必要があり、多くの場合 HTTP や FTP の URL です。前に設定した pkgname や pkgver 変数をここで使うことができます (例: source=(http://example.com/$pkgname-$pkgver.tar.gz))。

自作のパッチなど、オンザフライでダウンロードできないファイルを供給する必要があるときは、PKGBUILD ファイルがあるところと同じディレクトリにそのファイルを入れて source にファイル名を追加するだけです。ここに追加したパスはすべて PKGBUILD があるディレクトリから相対的に考えられます。本当のビルドプロセスが始まる前に、この行で参照されている全てのファイルがダウンロードされるか存在を確認します。もしファイルが欠けている場合は makepkg は次に進みません。

ヒント: ダウンロードされるファイルに異なる名前を指定するには - GET パラメータがある URL などが原因でダウンロードされるファイルの名前が異なる場合 - 次の構文を使って下さい: filename::fileuri, 例えば: source=("project_name::hg+https://googlefontdirectory.googlecode.com/hg/"。

ノート: .install ファイルは source に記述してはいけません。

拡張子が .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[@]%%::*})

validpgpkeys

PGP フィンガープリントの配列。validpgpkeys を使用した場合、makepkg は validpgpkeys に記載されている鍵の署名だけを使うようにして鍵束の値は無視します。ソースファイルが副鍵で署名されていた場合、makepkg は主鍵を使って比較します。

指定できるのは完全なフィンガープリントだけです。全て大文字で空白を含めてはいけません。

ノート: gpg --list-keys --fingerprint <KEYID> で指定した鍵のフィンガープリントを確認できます。

整合性

以下の変数はどれもチェックサム文字列を指定するようになっており、source 配列に書かれたファイルの整合性を確認するのに使われます。SKIP とすることで特定のファイルのチェックサムを確認しないようにできます。

チェックサムの種類と値は、リリースアナウンスなど上流から提供されたものを常に使用する必要があります。複数のタイプが利用可能な場合は、最も強力なチェックサムが優先されます。sha512 よりも b2, sha384 よりも sha384, sha256 よりも sha512 を優先してください, sha224 に対して sha256、sha1 に対して sha224、md5 に対して sha1、および md5 以上 ck} があります。これは、上流のアナウンスからパッケージのビルドまで、ダウンロードしたファイルの完全性を保証するために最適な方法です。

ノート: さらに、上流が デジタル署名 を利用可能にしたら、署名ファイルを source 配列に、PGP 鍵指紋を validpgpkeys 配列に追加する必要があります。これにより、ビルド時にファイルの認証ができるようになります。

これらの変数の値は makepkg の -g/--geninteg オプションで自動生成され、一般に makepkg -g >> PKGBUILD で追加されます。pacman-contrib の updpkgsums(8) コマンドは PKGBUILD 内のどこにあっても変数を更新することが可能です。どちらのツールも PKGBUILD に既に設定されている変数を使い、設定されていない場合は md5sums にフォールバックします。

使用するファイルの整合性チェックは /etc/makepkg.conf の INTEGRITY_CHECK オプションで設定することができます。 makepkg.conf(5) を参照してください。

ノート: 追加のアーキテクチャ固有の配列は、アンダースコアとアーキテクチャ名を付加することで追加できます、例えば sha256sums_x86_64=()

cksums

source 配列にリストされているファイルの CRC32 チェックサム (UNIX 標準 cksum より)

md5sums

source 行に含まれるファイルの 128 ビット MD5 チェックサムの文字列。

sha1sums

source 行に含まれるファイルの 160ビットの SHA-1 チェックサムの文字列。

sha256sums

ダイジェスト サイズが 256 ビットの SHA-2 チェックサムの配列。

sha224sums, sha384sums, sha512sums

それぞれ 224, 384, 512 ビットのダイジェストサイズの SHA-2 チェックサムの文字列。sha256sums の代替ですが、あまり一般的ではない代替手段です。

b2sums

BLAKE2 チェックサムの配列で、ダイジェスト サイズは 512 ビットです。

参照

• PKGBUILD(5) マニュアルページ
• サンプル PKGBUILD ファイル