AUR 投稿ガイドライン

関連記事

• Arch User Repository
• Arch パッケージガイドライン
• AUR Trusted User ガイドライン

ユーザーは Arch User Repository を使って PKGBUILD をシェアすることができます。AUR にはバイナリパッケージはありませんが、他のユーザがダウンロードできる PKGBUILD をアップロードできます。これらの PKGBUILD は完全に非公式なものであり、徹底して管理されてはいないので、自己責任において使うことになります。

パッケージを投稿する

警告: パッケージを投稿する前に、Arch パッケージングスタンダード や「関連記事」の記事すべてを熟知していることが期待されます。あなたのアップロードしようとしているものが正しいことを 慎重に検証してください。規則に違反するパッケージは、警告も無く 削除される 場合があります。

このセクションを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.

ノート: pkgbase が削除されたパッケージとマッチする場合、リポジトリは空にはなりません。

すでにパッケージを持っている場合、それが Git リポジトリでないならば、Git リポジトリとして初期化してください。そして AUR リモートリポジトリを追加してください:

$ git remote add label ssh://aur@aur.archlinux.org/pkgbase.git

次に、このリモートリポジトリをフェッチして初期化してください。

ノート: pkgbase が削除されたパッケージとマッチする場合、衝突を解決するために pull、rebase してください。

新しいパッケージコンテンツを公開する

警告: あなたのコミットは、あなたのグローバルな Git の名前と email アドレスによって認証されます。コミットを、push した後に変更するのは非常に困難です (FS#45425)。別の認証情報を使って AUR に push したい場合、パッケージごとに git config user.name "..." と git config user.email "..." を使って認証情報を変更することができます。

パッケージングされたソフトウェアの新しいバージョンをリリースする際は、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

ノート:

• .SRCINFO が最初のコミットに含まれていなかった場合、--root で rebase するかツリーをフィルタリングして追加してください。そうすれば、AUR は初期のプッシュを受け入れます。
• AUR は、master ブランチへのプッシュのみを許可します。ローカルのブランチに他の名前をつけている場合、名前を変更し、再びプッシュしてください。

ヒント: 作業ディレクトリとコミットもを可能な限り綺麗に保つには、すべてのファイルを除外する gitignore(5) を作成し、必要に応じてファイルを force-add してください。

パッケージをメンテナンスする

• 他のユーザーからのコメントやフィードバックをチェックして、ときには提案を汲み上げるようにしましょう。学習過程だと考えて下さい。
• パッケージを更新する度にバージョン番号を含むコメントを投稿するのはやめてください。コメント欄は、上記で説明したような意味ある内容のために使って下さい。
• パッケージを投稿したらそのまま放置するのはやめてください。アップデートをチェックし、PKGBUILD を修正してパッケージをメンテナンスするのがメンテナの仕事です。
• 何らかの理由でパッケージのメンテナンスが続けられない場合は、AUR ウェブインタフェースでパッケージを disown するか、メーリングリストにメッセージを投稿してください。AUR パッケージのメンテナがパッケージを放棄すると、パッケージは"孤児"パッケージになります。

リクエスト

孤児リクエスト、消去リクエスト、マージリクエストは右側の "パッケージアクション" の下にある "リクエストを送る" リンクをクリックして作成することができます。リクエストが作成されると自動的に通知メールがパッケージの現在のメンテナと aur-requests メーリングリスト に送信されます。その後 Trusted Users がリクエストの承認・却下を行います。

• 孤児リクエストは、現在のメンテナが応答しない場合、通るのに2週間掛かります。例外は、180 日間以上パッケージに out-of-date フラグが立てられている場合です。この場合、孤児リクエストは自動的に受理されます。
• マージリクエストは、パッケージベースを削除し、票とコメントを他のパッケージベースに転送します。マージ先のパッケージベースの名前が必要です。これは 'git merge' や GitLab のマージリクエストとは関係ないことに注意してください。
• 消去リクエストには以下の情報が必要です:
  • 削除の理由を説明する短いノート。パッケージのコメント欄は、パッケージを削除する理由を説明するのに十分でないことに注意してください。TU が行動を起こしてすぐにそのような情報を入手できる場所は aur-requests メーリングリストだけだからです。
  • 補足事項を加えて下さい。仮にあなたがメンテナならば、他のパッケージで提供されるようになった、パッケージ名を変えて元の管理者が認めた、など。
  • パッケージが削除されたあとも、その Git リポジトリは AUR で利用可能なままです。

翻訳ステータス: このページは en:AUR submission guidelines の翻訳バージョンです。最後の翻訳日は 2022-10-29 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。