AUR 投稿ガイドライン
ユーザーは Arch User Repository を使って PKGBUILD スクリプトをシェアすることができます。AUR にはバイナリパッケージはありませんが、他のユーザがダウンロードできる PKGBUILD をアップロードできます。これらの PKGBUILD は完全に非公式なものであり、徹底して管理されてはいないので、自己責任において使うことになります。
目次
パッケージを投稿する
このセクションを2度読んでもパッケージやビルド/投稿のプロセスに分からないことがあれば、AUR に投稿する前に、AUR メーリングリストや Arch フォーラムの AUR フォーラムに PKGBUILD を投稿するか、IRC チャンネル で公開レビューを依頼してください。
投稿の規則
パッケージを AUR に投稿する際には、以下のルールを守りましょう:
- 投稿する PKGBUILD は、いかなる状況であっても、公式 バイナリ リポジトリに すでに存在する アプリケーションをビルドするものであってはいけません。公式パッケージデータベースでパッケージをチェックしてください。そのパッケージの任意のバージョンが存在する場合、そのパッケージを投稿しないでください。公式のパッケージが out-of-date である場合、そのフラグを立ててください。公式のパッケージが壊れている、あるいは機能不足である場合、バグレポートを提出してください。
- この厳格な規則の例外は、パッケージが公式のパッケージと比べて 追加の機能 が有効化されていたり パッチ が当てられていたりする場合のみです。そのような場合は、
pkgnameが、その違いを表すように異なっているべきです。例えば、サイドバーのパッチを適用した GNU screen のパッケージはscreen-sidebarなどと名前を付けます。さらに、公式パッケージと衝突しないようにするためにconflicts=('screen')配列を使う必要があります。
- そのパッケージがすでに存在してないか AUR をチェックしてください。メンテナンスされているパッケージがあるのならば、コメントからメンテナに修正を求めることができます。パッケージがメンテナンスされておらず、かつメンテナが応答しないならば、必要に応じてそのパッケージを継承し、更新することができます。重複したパッケージを作成しないでください。
- 投稿するパッケージが皆の役に立つか考えて下さい。他の誰かがそのパッケージを使おうと考えるでしょうか？あまりにも特殊化しすぎていませんか？少なからぬ人が役に立つと思うようなパッケージであれば、投稿するのにふさわしいでしょう。
- AUR と公式リポジトリは、一般的にソフトウェアやソフトウェアに関連するコンテンツをインストールするパッケージのために存在します。該当するコンテンツとしては次のものが含まれます: 実行可能ファイル、設定ファイル、特定のソフトウェアもしくは Arch Linux ディストリビューション全体のオンライン・オフラインのドキュメント、ソフトウェアによって直接使用されるメディア。
- AUR の PKGBUILD で
replacesを使うのはパッケージの名前を変更したいときに限ります。例えば Ethereal から Wireshark に名前が変更されたときのようにです。既存のパッケージの別バージョンとしてパッケージを作成する場合、conflictsを使ってください (他のパッケージから必要とされる場合はprovidesも使ってください)。conflictsとreplacesは、同期後 (-Sy) に pacman が即座にパッケージを置き換えるかどうかが違います。conflictsはパッケージのインストール時にしか評価されません。
- バージョン管理システムからビルドし、特定のバージョンに結び付かないパッケージには、(git の場合は
-gitといった) 適切な接尾辞を付ける必要があります。接尾辞の完全なリストは VCS パッケージガイドライン#パッケージの命名 を参照してください。
- ビルド済みの成果物を使うパッケージには、ソースコードが利用可能な場合は、
-binサフィックスを付けなければなりません。この規則の例外として、Java を使う場合です。AUR には、makepkg によって作成されたバイナリ tarball や、filelist が含まれているべきではありません。
- 特定のバージョンを用いてソースからビルドするパッケージには、接尾辞を用いません。
PKGBUILDファイルのトップには、現在の メンテナ と以前の 貢献者 の情報を含む コメント行 を、以下の形式に沿って追加してください。スパムから身を守るためにメールアドレスをぼかしましょう。追加/不必要な行は任意です。
- もしあなたが既存の PKGBUILD のメンテナの役割を引き受けるのであれば、以下のようにあなたの名前をトップに追加してください。
# Maintainer: Your Name <address at domain dot tld>
- 以前のメンテナがいたのであれば、彼らを貢献者として追加してください。これがあなたでなければ、オリジナルの投稿者に対しても同様です。あなたが共同メンテナであるならば、現在の他のメンテナの名前も追加してください。
# Maintainer: Your name <address at domain dot tld> # Maintainer: Other maintainer's name <address at domain dot tld> # Contributor: Previous maintainer's name <address at domain dot tld> # Contributor: Original submitter's name <address at domain dot tld>
認証
AUR への書き込みアクセス権を得るには、SSH 鍵のペアが必要です。公開鍵の内容は My Account のプロファイルにコピーする必要があります。対応する秘密鍵は aur.archlinux.org ホスト用に設定してください。例えば:
~/.ssh/config
Host aur.archlinux.org IdentityFile ~/.ssh/aur User aur
何かが起こった時に SSH 鍵を選択的に無効化できるように、既存の SSH 鍵を使うのではなく、新しく鍵のペアを作成するべきです:
$ ssh-keygen -f ~/.ssh/aur
パッケージのリポジトリを作成する
ゼロから新しいパッケージを作成しているのであれば、目的の pkgbase をクローンして、ローカルの Git リポジトリと AUR リモートリポジトリを作る必要があります。パッケージがまだ存在しない場合、以下の警告が表示されるでしょう:
$ git clone ssh://aur@aur.archlinux.org/pkgbase.git
Cloning into 'pkgbase'... warning: You appear to have cloned an empty repository. Checking connectivity... done.
すでにパッケージを持っている場合、それが Git リポジトリでないならば、Git リポジトリとして初期化してください。そして AUR リモートリポジトリを追加してください:
$ git remote add label ssh://aur@aur.archlinux.org/pkgbase.git
次に、このリモートリポジトリをフェッチして初期化してください。
新しいパッケージコンテンツを公開する
パッケージングされたソフトウェアの新しいバージョンをリリースする際は、pkgver 変数か pkgrel 変数を更新して、すべてのユーザにアップグレードが必要であることを通知してください。typo の修正など、PKGBUILD のマイナーな変更だけの場合は、これらの値を更新しないでください。
VSC パッケージの単なる pkgver バージョンアップはコミットしないでください。それらは、上流に新しいコミットがある場合に、out-of-date とみなされません。新しいコミットをするのは、他の変更 (ビルドプロセスの変更など) が発生した場合に限ります。
PKGBUILD メタデータが変更された際 (pkgver() が更新されたときなど) は必ず .SRCINFO を再生成してください。さもないと、AUR は更新後のバージョン番号を表示しません。
パッケージをアップロード/アップデートするには、少なくとも PKGBUILD と .SRCINFO を、次に追加の新しい/変更された補助ファイル (.install ファイルや、パッチなどのローカルのソースファイル) 追加してください。そして、意味のあるコミットメッセージを付けてコミットし、最後に変更を AUR にプッシュしてください。
例:
$ makepkg --printsrcinfo > .SRCINFO $ git add PKGBUILD .SRCINFO $ git commit -m "useful commit message" $ git push
パッケージをメンテナンスする
- 他のユーザーからのコメントやフィードバックをチェックして、ときには提案を汲み上げるようにしましょう。学習過程だと考えて下さい。
- パッケージを更新する度にバージョン番号を含むコメントを投稿するのはやめてください。コメント欄は、上記で説明したような意味ある内容のために使って下さい。
- パッケージを投稿したらそのまま放置するのはやめてください。アップデートをチェックし、PKGBUILD を修正してパッケージをメンテナンスするのがメンテナの仕事です。
- 何らかの理由でパッケージのメンテナンスが続けられない場合は、AUR ウェブインタフェースでパッケージを
disownするか、メーリングリストにメッセージを投稿してください。AUR パッケージのメンテナがパッケージを放棄すると、パッケージは"孤児"パッケージになります。 - 自動化はメンテナにとって価値のあるツールですが、手動介入を置き換えることはできません (例: プロジェクトは、たとえ「マイナー」リリースであっても、ライセンスの変更、依存関係の追加/削除、その他の重要な変更を行う可能性があります)。自動的に作成された PKGBUILD の更新は自己責任で使用してください。機能不全に陥ったアカウントやそのパッケージは予告もなく削除される場合があります。
リクエスト
削除リクエスト、マージリクエスト、孤児リクエストは右側の "パッケージアクション" の下にある "リクエストを送信" リンクをクリックして作成することができます。リクエストが作成されると通知メールがパッケージの現在のメンテナと aur-requests メーリングリスト に送信されます。その後 Trusted Users がリクエストの承認・却下を行います。
削除
AUR から pkgbase を削除するリクエストです。削除の理由とそれの裏付けとなる詳細 (他のパッケージによってパッケージが提供されている、あなた自身がメンテナである、パッケージの名称が変更された、元の所有者が同意したなど) を説明する短いノートが必要です。
マージ
pkgbase の削除を行い、その投票数とコメントを他の pkgbase に移動させるリクエストです。マージ先のパッケージの名前が必要です。
孤児
pkgbase を放棄させるリクエストです。現在のメンテナが応答しない場合、このリクエストは2週間後に受理されます。例外は、パッケージに out-of-date フラグが少なくとも180日間建てられている場合です。この場合、孤児リクエストは自動的に受理されます。