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>

認証

For write access to the AUR, you need to have an SSH key pair. The content of the public key needs to be copied to your profile in My Account, and the corresponding private key configured for the aur.archlinux.org host. For example:

~/.ssh/config

Host aur.archlinux.org
  IdentityFile ~/.ssh/aur
  User aur

You should create a new key pair rather than use an existing one, so that you can selectively revoke the keys should something happen:

$ ssh-keygen -f ~/.ssh/aur

ヒント: You can add multiple public keys to your profile by separating them with a newline in the input field.

パッケージのリポジトリを作成する

If you are creating a new package from scratch, establish a local Git repository and an AUR remote by cloning the intended pkgbase. If the package does not yet exist, the following warning is expected:

$ git clone ssh://aur@aur.archlinux.org/pkgbase.git

Cloning into 'pkgbase'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

ノート: The repository will not be empty if pkgbase matches a deleted package.

If you already have a package, initialize it as a Git repository if it is not one, and add an AUR remote:

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

Then fetch this remote to initialize it in the AUR.

ノート: Pull and rebase to resolve conflicts if pkgbase matches a deleted package.

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

警告: 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 で利用可能なままです。