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などと名前を付けます。さらに、公式パッケージと衝突しないようにするためprovides=('screen')を使ってください。
- そのパッケージがすでに存在してないか AUR をチェックしてください。メンテナンスされているパッケージがあるのならば、コメントからメンテナに修正を求めることができます。パッケージがメンテナンスされておらず、かつメンテナが応答しないならば、必要に応じてそのパッケージを継承し、更新することができます。重複したパッケージを作成しないでください。
- 投稿するパッケージが皆の役に立つか考えて下さい。他の誰かがそのパッケージを使おうと考えるでしょうか？あまりにも特殊化しすぎていませんか？少なからぬ人が役に立つと思うようなパッケージであれば、投稿するのにふさわしいでしょう。
- AUR と公式リポジトリは、一般的にソフトウェアやソフトウェアに関連するコンテンツをインストールするパッケージのために存在します。該当するコンテンツとしては次のものが含まれます: 実行可能ファイル、設定ファイル、特定のソフトウェアもしくは Arch Linux ディストリビューション全体のオンライン・オフラインのドキュメント、ソフトウェアによって直接使用されるメディア。
- AUR の PKGBUILD で
replacesを使うのはパッケージの名前を変更したいときです。例えば Ethereal から Wireshark に名前が変更されたときのようにです。既存のパッケージの別バージョンとしてパッケージを作成する場合、conflictsを使ってください (他のパッケージから必要とされる場合はprovidesも使ってください)。conflictsとreplacesは、同期後 (-Sy) に pacman が即座にパッケージを置き換えるかどうかが違います。conflictsはパッケージのインストール時にしか評価されません。
- ビルド済みの成果物を使うパッケージには、ソースコードが利用可能な場合は、
-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 パッケージのメンテナがパッケージを放棄すると、パッケージは"孤児"パッケージになります。
リクエスト
孤児リクエスト、消去リクエスト、マージリクエストは右側の "パッケージアクション" の下にある "リクエストを送る" リンクをクリックして作成することができます。リクエストが作成されると自動的に通知メールがパッケージの現在のメンテナと aur-requests メーリングリスト に送信されます。その後 Trusted Users がリクエストの承認・却下を行います。
- 孤児リクエストは、現在のメンテナが応答しない場合、通るのに2週間掛かります。例外は、180 日間以上パッケージに out-of-date フラグが立てられている場合です。この場合、孤児リクエストは自動的に受理されます。
- マージリクエストは、パッケージベースを削除し、票とコメントを他のパッケージベースに転送します。マージ先のパッケージベースの名前が必要です。これは 'git merge' や GitLab のマージリクエストとは関係ないことに注意してください。
- 消去リクエストには以下の情報が必要です:
- 削除の理由を説明する短いノート。パッケージのコメント欄は、パッケージを削除する理由を説明するのに十分でないことに注意してください。TU が行動を起こしてすぐにそのような情報を入手できる場所は aur-requests メーリングリストだけだからです。
- 補足事項を加えて下さい。仮にあなたがメンテナならば、他のパッケージで提供されるようになった、パッケージ名を変えて元の管理者が認めた、など。
- パッケージが削除されたあとも、その Git リポジトリは AUR で利用可能なままです。