PKGBUILD (日本語) - ArchWiki

# PKGBUILD (日本語)

関連記事

- Arch Packaging Standards
- Arch Build System
- パッケージの作成
- :Category:パッケージ開発
- カスタムローカルリポジトリ
- pacman Tips
- Arch User Repository
- makepkg
- pacman

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 の構文が正しければ問題ありません。

### pkgname

パッケージの名前。含めることができる文字は英数字と記号 @ . _ + - (アットマーク、ドット、アンダーバー、プラス、ハイフン)です。全ての文字は小文字でなくてはならず名前の最初をハイフンにすることはできません。一貫性を保つために、`pkgname` はパッケージするソース tarball の名前と一致させてください。例えば、ソフトウェアが `foobar-2.5.tar.gz` なら、`pkgname` の値は `foobar` にするべきです。PKGBUILD ファイルを入れる作業ディレクトリも `pkgname` と一致させる必要があります。

### pkgver

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

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

### pkgrel

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

### pkgdir

この変数はパッケージに入れられるものの root ディレクトリになります。基本的に `make DESTDIR="$pkgdir" install` のように使われます。

### epoch

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

### pkgbase

分割パッケージをビルドするときに包括的な選択の指示ができるときに、makepkg の出力やソースだけの tarball の名前付けで pkgbase がパッケージのグループを参照するために使われます。指定されていない場合、pkgname 行の初めの部分が使われます。分割パッケージでは全てのオプションと指示が PKGBUILD の包括的な値のデフォルトになります。ただし、分割パッケージのパッケージ関数内で次の値は上書き可能です: pkgver, pkgrel, epoch, pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install, changelog。この変数では最初にハイフンを使うことはできません。

### pkgdesc

パッケージの説明。説明は80文字以下でなくてはならず、また説明の中にパッケージ名を含めて自己参照してはいけません。例えば、"Nedit is a text editor for X11" は "A text editor for X11" に書き換えてください。

Note: AUR にパッケージを投稿するときは、このルールにむやみに従ってはいけません。何らかの理由でパッケージの名前がアプリケーションの名前と異なる場合、検索でパッケージを表示する唯一の方法はフルネームを説明に入れることです。

### arch

`PKGBUILD` がビルド・動作するアーキテクチャの文字列。現在、`i686` と `x86_64`、`arch=('i686' 'x86_64')` が使えます。アーキテクチャに依存しないパッケージには `any` を使うことができます。

`$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] を含む`) 公式リポジトリの２つ以上のパッケージで使われると、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` を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。

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

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

Note: 既に `depends` に含まれているパッケージを指定する必要はありません。
Warning: makepkg でビルドする際 base-devel グループは既にインストールされているものと前提されます。"base-devel" のパッケージを `makedepends` 行に入れてはいけません。

### 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[broken link: replaced by wireshark-gtk] パッケージには `replaces=('ethereal')`。`pacman -Sy` で同期をした後、リポジトリ内の `replaces` に一致する他のパッケージが現れるとインストールされたパッケージを置き換えます。既存のパッケージの別バージョンを提供するときは、衝突するパッケージをインストールするときに評価される `conflicts` 変数を使って下さい。

### backup

ユーザーが作成した変更を含んだり、パッケージのアップグレードや削除が行われても維持されるファイルの文字列、主に `/etc` 内の設定ファイル用。

アップデート時、既存のファイル（ユーザーによって修正されたファイル）を上書きしないために新しいバージョンは `file.pacnew` として保存されます。同じく、パッケージの削除時、パッケージを削除するのに `pacman -Rn` コマンドを使わなければ、ユーザーが修正したファイルは `file.pacsave` として残されます。

この行のファイルパスは絶対パス (例: `/etc/pacman.conf`) ではなく相対パス (例: `etc/pacman.conf`) にしてください。Pacnew and Pacsave Files も参照。

### 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` スクリプトの名前。パッケージのインストール・削除・アップグレードの際に、pacman はパッケージごとにスクリプトを保存・実行する機能があります。スクリプトには実行される時期によって以下の関数を含めます:

- pre_install - ファイルが展開される前にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。
- post_install - ファイルが展開された後にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。
- pre_upgrade - ファイルが展開される前にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。
- post_upgrade - ファイルが展開された後にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。
- pre_remove - ファイルが削除される前にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。
- post_remove - ファイルが削除された後にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。

それぞれの関数は pacman のインストールディレクトリの中に chroot されて実行されます。このスレッドを見て下さい。

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

### changelog

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

    pacman -Qc pkgname

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

### source

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

Note: 自作のパッチなど、オンザフライでダウンロードできないファイルを供給する必要があるときは、`PKGBUILD` ファイルがあるところと同じディレクトリにそのファイルを入れて source にファイル名を追加するだけです。ここに追加したパスはすべて `PKGBUILD` があるディレクトリから相対的に考えられます。本当のビルドプロセスが始まる前に、この行で参照されている全てのファイルがダウンロードされるか存在を確認します。もしファイルが欠けている場合は `makepkg` は次に進みません。
Tip: ダウンロードされるファイルに異なる名前を指定するには - GET パラメータがある URL などが原因でダウンロードされるファイルの名前が異なる場合 - 次の構文を使って下さい: `filename::fileuri`, 例えば: `source=("project_name::hg+https://googlefontdirectory.googlecode.com/hg/"`。

### noextract

`source` 行で `makepkg` によって圧縮フォーマットを展開してはいけないファイルの文字列。libarchive は unzip とは違い全てのファイルをランダムアクセスではなくストリームで処理するので、`/usr/bin/bsdtar` によって扱えない圧縮ファイルに noextract を使うのがほとんどです。こういった場合には他の解凍ツール (例: `unzip`, `p7zip` など) を `makedepends` に追加して prepare() 関数の最初の行でソースの圧縮ファイルを手動で展開する必要があります。例えば:

    unzip [source].zip

`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[@]%%::*})

Note: More conservative Bash substitution would include quotes, or possibly even a loop that calls `basename`. If you have read this far, you should get the idea.

### md5sums

`source` 行に含まれるファイルの MD5 チェックサムの文字列。`source` 行の全てのファイルが利用できるようになると、それぞれのファイルの MD5 ハッシュが自動で生成され `source` 行と同じ順番で md5sums の値と比較されます。ソースファイルの順番自体に意味はありませんが、`makepkg` はどのチェックサムがどのソースファイルにあたるか考慮しないので md5sums の順番が一致していることは重要です。`PKGBUILD` ファイルが含まれているディレクトリで `updpkgsums` や `makepkg -g` コマンドを使うことで簡単に素早くこの行を生成することができます。

Note: MD5 アルゴリズムには脆弱性があることが知られています。より強固なアルゴリズムを使うことも考えるべきでしょう。

### 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` を参照。

## 参照

- PKGBUILD(5) Manual Page
- Example PKGBUILD file
- Example .install file

Category:

- Package development (日本語)