Arch Packaging Standards (日本語) - ArchWiki

# Arch Packaging Standards (日本語)

いかなる場合でも公式のバイナリリポジトリに既にあるアプリケーションをビルドする 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, etc) パッケージ

Arch VCS PKGBUILD guidelines を見て下さい

### Eclipse プラグインパッケージ

Eclipse plugin package guidelines を見て下さい

### GNOME パッケージ

GNOME Package Guidelines を見て下さい

### Go パッケージ

Go Package Guidelines を見て下さい linux

### Haskell パッケージ

Haskell package guidelines を見て下さい

### Java パッケージ

Java Package Guidelines を見て下さい

### KDE パッケージ

KDE Package Guidelines を見て下さい

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

Kernel Module Package Guidelines を見て下さい

### Lisp パッケージ

Lisp Package Guidelines を見て下さい

### OCaml パッケージ

OCaml_Package_Guidelines を見て下さい

### Perl パッケージ

Perl Package Guidelines を見て下さい

### Python パッケージ

Python Package Guidelines を見て下さい

### Ruby Gem パッケージ

Ruby Gem Package Guidelines を見て下さい

### Wine パッケージ

Arch wine PKGBUILD guidelines を見て下さい

### MinGW パッケージ

MinGW PKGBUILD guidelines を見て下さい

Categories:

- About Arch (日本語)
- Package management (日本語)
- Package development (日本語)