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

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

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

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

警告: Your commits will be authored with your global Git name and email address. It is very difficult to change commits after pushing them (FS#45425). If you want to push to the AUR under different credentials, you can change them per package with git config user.name "..." and git config user.email "...".

When releasing a new version of the packaged software, update the pkgver or pkgrel variables to notify all users that an upgrade is needed. Do not update those values if only minor changes to the PKGBUILD such as the correction of a typo are being published.

Do not commit mere pkgver bumps for VCS packages. They are not considered out of date when the upstream has new commits. Only do a new commit when other changes are introduced, such as changing the build process.

Be sure to regenerate .SRCINFO whenever PKGBUILD metadata changes, such as pkgver() updates; otherwise the AUR will not show updated version numbers.

To upload or update a package, add at least PKGBUILD and .SRCINFO, then any additional new or modified helper files (such as .install files or local source files such as patches), commit with a meaningful commit message, and finally push the changes to the AUR.

For example:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push

ノート:

• If .SRCINFO was not included in your first commit, add it by rebasing with --root or filtering the tree so the AUR will permit your initial push.
• The AUR only allows pushes to the master branch. If the local branch is named something else, rename it and push again.

ヒント: To keep the working directory and commits as clean as possible, create a gitignore(5) that excludes all files and force-add files as needed.

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

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

リクエスト

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

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