Arch パッケージガイドライン

いかなる場合でも公式のバイナリリポジトリに既にあるアプリケーションをビルドする PKGBUILD を投稿してはいけません。このルールの唯一の例外は公式のものに対して新しい機能やパッチがパッケージに加えられている場合です。そのようなときは、pkgname 行は異なっている必要があります。

Arch Linux のためにパッケージを作成するときは―特に新しいパッケージを Arch Linux に貢献するのが目的のときは―以下のパッケージガイドラインを守って下さい。PKGBUILD や makepkg の man ページも見て下さい。

PKGBUILD プロトタイプ

# Maintainer: Your Name <youremail@domain.com>
pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=()
url=""
license=('GPL')
groups=()
depends=()
makedepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
changelog=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #generate with 'makepkg -g'

build() {
  cd "$srcdir/$pkgname-$pkgver"

  ./configure --prefix=/usr
  make
}

package() {
  cd "$srcdir/$pkgname-$pkgver"

  make DESTDIR="$pkgdir/" install
}

他にも pacman や abs パッケージからのプロトタイプが /usr/share/pacman にあります。

パッケージエチケット

• パッケージは /usr/local にインストールしてはいけません
• パッケージがそれなしではビルドできないという状態を除いて、PKGBUILD ビルドスクリプトに新しい変数を使ってはいけません。makepkg で使われている変数と衝突する恐れがあるからです。 新しい変数がどうしても必要な時は、 変数の名前の前にアンダーバーを付けて下さい (_), 例:

  _customvariable=

  AUR はカスタム変数の使用を検知できないのでそれらを代わりに使うことはできません。これは多くの場合 source 行で問題になります、例:

  http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2

  これでは AUR の機能を破壊してしまいます。

• いかなるものにも /usr/libexec/ を使うことは避けてください。代わりに /usr/lib/${pkgname}/ を使って下さい。
• パッケージメタファイルの packager フィールドはパッケージ作成者が /etc/makepkg.conf 内の適切なオプションを修正するか、~/.makepkg.conf を作成して上書きすることでカスタマイズすることができます
• 重要なメッセージは全てインストール中に .install ファイルを使って表示してください。例えば、パッケージを動作させるのに追加のセットアップが必要な時は、説明を加えて下さい。
• それがなくても動作したり、一般的な機能には必要ない提案パッケージ（任意依存パッケージ）を含めてはいけません; そうした情報は 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')

  上記のサンプルは extra の wine パッケージです。optdepends の情報はインストールやアップグレードのときに自動で表示されます。従ってこの種の情報は .install ファイルに記入してはいけません。

• パッケージのパッケージ説明を作る時は、パッケージの名前を繰り返さないで下さい。 例えば、"Nedit is a text editor for X11" はシンプルに "A text editor for X11" にできます。また、説明は80文字以下に抑えて下さい。
• PKGBUILD 内の行の長さは100文字以下にしてください。
• できるだけ、PKGBUILD から空の行を削除してください (provides, replaces, etc.)
• PKGBUILD の項目は上記の順番を守るのが常識になっています。ただし、これは強制ではありません、中身が正しい bash 構文なら大丈夫です。

パッケージの命名

• パッケージの名前は英数字だけでなくてはなりません; 全ての文字は小文字でなくてはなりません。
• パッケージのバージョンは作者によってリリースされたバージョンと同じでなくてはなりません。必要ならばバージョンには文字を入れることもできます (例, nmap のバージョンは 2.54BETA32)。バージョンタグにハイフンを含めることはできません！文字、数字およびピリオドのみです。
• パッケージリリースは Arch Linux のパッケージ特有のものです。パッケージビルドの新旧をユーザーが見分けられるようにするためにあります。新しいパッケージバージョンがリリースされたとき、リリースカウントは1から始まります。修正や最適化がなされるたびに、パッケージは Arch Linux ユーザーに再リリースされリリース番号が増加します。新しいバージョンが出ると、リリースカウントは1にリセットします。パッケージのリリースタグはバージョンタグと同じ命名規則に従います。

ディレクトリ

• 設定ファイルは /etc ディレクトリに置いて下さい。設定ファイルが複数ある場合は、/etc をきれいに保つためにサブディレクトリを使うのが慣例です。/etc/{pkgname}/ を使って下さい ({pkgname} はパッケージの名前 (もしくはその他の相応しい名前, 例, apache は /etc/httpd/ を使っています))。
• パッケージファイルは以下の一般ディレクトリガイドラインに従って下さい:

/etc	システムの重要な設定ファイル
/usr/bin	バイナリ
/usr/lib	ライブラリ
/usr/include	ヘッダファイル
/usr/lib/{pkg}	モジュール、プラグインなど
/usr/share/doc/{pkg}	アプリケーションのドキュメント
/usr/share/info	GNU Info system ファイル
/usr/share/man	Manpages
/usr/share/{pkg}	アプリケーションのデータ
/var/lib/{pkg}	アプリケーションの永続的なストレージ
/etc/{pkg}	{pkg} の設定ファイル
/opt/{pkg}	Java などの巨大な内蔵パッケージ。

• パッケージに以下のディレクトリを含めてはいけません:
  • /dev
  • /home
  • /srvarch wiki
  • /media
  • /mnt
  • /proc
  • /root
  • /selinux
  • /sys
  • /tmp
  • /var/tmp

Makepkg が行うこと

パッケージをビルドするのに makepkg が使われると、makepkg は以下のことを自動で行います:

1. パッケージの依存パッケージや提案パッケージがインストールされているかチェック
2. サーバーからソースファイルをダウンロード
3. ソースファイルの整合性を確認
4. ソースファイルを解凍
5. 必要なパッチの適用
6. fake root 環境でのソフトウェアのビルドとインストール
7. バイナリからシンボルを除去
8. ライブラリからデバッグ用のシンボルを除去
9. manual や info ページを圧縮
10. それぞれのパッケージに含まれるパッケージメタファイルを生成
11. fake root を圧縮してパッケージファイルを生成
12. パッケージファイルを指定されたディレクトリに保存 (デフォルトでは cwd に保存)

アーキテクチャ

arch 行にはビルドできるアーキテクチャによって 'i686' や 'x86_64' を入力します。アーキテクチャに依存しないパッケージには 'any' を使うこともできます。

ライセンス

公式リポジトリでは license 行が使われています、同じようにあなたのパッケージでも使うべきです。使い方は次の通り:

• [core] の licenses パッケージはよく使われるライセンスを /usr/share/licenses/common に保存します。例: /usr/share/licenses/common/GPL。パッケージのライセンスがここに保存されているライセンスのどれかのときは、ディレクトリの名前を設定してください、例: license=('GPL')
• 適切なライセンスが公式の licenses パッケージに含まれていない場合は、やる必要があることがいくつかあります:
  1. ライセンスファイルを次のディレクトリに含めなくてはなりません: /usr/share/licenses/$pkgname/ , 例: /usr/share/licenses/dibfoo/LICENSE。次の一行でこれを行えます:

     install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

  2. ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。
  3. license 行に 'custom' を加えて下さい。任意で、'custom' を 'custom:"name of license"' に置き換えることもできます。
• あるライセンスが ([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:some commercial license")。パッケージの大多数は、一度に適用されるのでなく、異なるケースでライセンスが適用されます。pacman にライセンスでフィルターをかける機能ができたら（つまり、"GPL と BSD ライセンスのソフトウェアだけが欲しい"などと言える）デュアルライセンスは pacman によって AND ではなく OR で扱われます。他のライセンスが挙げられているのかかわらず、pacman は上記のサンプルを GPL ライセンスのソフトウェアだと認識します。
• (L)GPL には多くのバージョンと組み合わせが存在します。(L)GPL ソフトウェアで使えるのは:
  • (L)GPL - (L)GPLv2 もしくはそれ以降のバージョン
  • (L)GPL2 - (L)GPL2 のみ
  • (L)GPL3 - (L)GPL3 もしくはそれ以降のバージョン

パッケージを AUR に投稿する

AUR にパッケージを投稿する前に以下のことに注意してください:

1. いかなる場合でも既に公式のバイナリリポジトリにあるアプリケーションをビルドする PKGBUILD を投稿してはいけません。このルールの唯一の例外は公式のものに対して新しい機能やパッチがパッケージに加えられている場合です。そのようなときは、pkgname 行は異なっている必要があります。 例: サイドバーパッチを含んだ GNU screen の PKGBUILD は screen-sidebar などの名前にして投稿してください。さらに、公式パッケージとの衝突を避けるために provides=('screen') を使わなくてはなりません。
2. AUR に投稿するパッケージのセキュリティを保証するために、md5sum を正しく入力するようにしてください。md5sum の値は makepkg -g コマンドを使って生成できます。
3. 次のフォーマットに従って PKGBUILD ファイルの一番上にコメント行を追加するようにお願いします。 スパム避けのためにあなたのメールアドレスを偽装することを覚えておきましょう:

   # Maintainer: Your Name <address at domain dot com>

   既存の PKGBUILD のメンテナーを引き継ぐときは、以前のメンテナーを Contributor に変えて、あなたの名前を上記の通りに追加してください:

   # Maintainer: Your Name <address at domain dot com>
   # Contributor: Previous Name <address at domain dot com>

4. パッケージの依存関係を確認してください (例: 動的な実行ファイルで ldd を実行して必要なツールを確認する、など)。 TU チームは Jason Chu によって書かれた namcap ユーティリティを使ってパッケージのサニティを分析することを強く推奨します。namcap は不正なパーミッション、欠けている依存パッケージ、不必要な依存パッケージなどの一般的な手違いを警告します。namcap パッケージは pacman でインストール可能です。 pkg.tar.gz ファイルと PKGBUILD の両方をチェックできる namcap を覚えておいて下さい
5. よくあるパッケージングの誤りとして依存関係の誤りがあります。Namcap は検知の助けになりますが、いつでも正しいわけではありません。ソースドキュメントやプログラムのウェブサイトを見て依存関係を確認してください。
6. Ethereal が Wireshark になったときなど、パッケージの名前が変わったとき以外は replaces を使わないで下さい。パッケージが既存のパッケージの別バージョンのときは、conflicts (パッケージが他のパッケージから必要とされているときは provides) を使って下さい。主な違いは: replaces は pacman を同期させた後すぐにインストール済みの'邪魔な'パッケージを置き換えますが; conflicts はパッケージをインストールするときにだけ調査されます。通常これは侵襲性が低いときの望ましい挙動になります。
7. AUR にアップロードする全てのファイルは PKGBUILD と追加のビルドファイル (patches, install, ...) を含んだディレクトリの圧縮された tar ファイルである必要があります。

   foo/PKGBUILD
   foo/foo.install
   foo/foo_bar.diff
   foo/foo.rc.conf

   アーカイブの名前はパッケージの名前を含めてください 例: foo.tar.gz。

   makepkg --source を使うことで全ての必要なファイルが入った tarball を簡単に作成することができます。このコマンドでは $pkgname-$pkgver-$pkgrel.src.tar.gz という名前の tarball が作成され、これはこのまま AUR にアップロードすることができます。

   tarball にファイルリストに含まれるバイナリや makepkg で作成したバイナリの tarball を含めてはいけません

追加ガイドライン

最初に上記のガイドラインを読んで下さい - このページで挙げた重要なポイントは、以下のガイドラインページでは繰り返しません。以下のガイドラインはこのページのスタンダードへの追加として存在します。

VCS (SVN, GIT, HG など) パッケージ

VCS PKGBUILD ガイドラインを見て下さい

Eclipse プラグインパッケージ

Eclipse プラグインパッケージガイドラインを見て下さい

GNOME パッケージ

GNOME パッケージガイドラインを見て下さい

Go パッケージ

Go パッケージガイドラインを見て下さい

Haskell パッケージ

Haskell パッケージガイドラインを見て下さい

Java パッケージ

Java パッケージガイドラインを見て下さい

KDE パッケージ

KDE パッケージガイドラインを見て下さい

カーネルモジュールパッケージ

カーネルモジュールパッケージガイドラインを見て下さい

Lisp パッケージ

Lisp パッケージガイドラインを見て下さい

OCaml パッケージ

OCaml パッケージガイドラインを見て下さい

Perl パッケージ

Perl パッケージガイドラインを見て下さい

Python パッケージ

Python パッケージガイドラインを見て下さい

Ruby Gem パッケージ

Ruby パッケージガイドラインを見て下さい

Wine パッケージ

Arch wine PKGBUILD ガイドラインを見て下さい

MinGW パッケージ

MinGW PKGBUILD ガイドラインを見て下さい