AUR 投稿ガイドライン

関連記事

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

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

パッケージを投稿する

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

このセクションを2度読んでもパッケージやビルド/投稿のプロセスに分からないことがあれば、AUR に投稿する前に、AUR メーリングリストや Arch フォーラムの AUR フォーラムに PKGBUILD を投稿するか、IRC チャンネル で公開レビューを依頼してください。

投稿の規則

When submitting a package to the AUR, observe the following rules:

• The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.

• Check the AUR if the package already exists. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained or the maintainer is unresponsive, the package can be adopted and updated as required. Do not create duplicate packages.

• Make sure the package you want to upload is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.

The AUR and official repositories are intended for packages which install generally software and software-related content, including one or more of the following: executable(s); configuration file(s); online or offline documentation for specific software or the Arch Linux distribution as a whole; media intended to be used directly by software.

• Do not use replaces in an AUR PKGBUILD unless the package is to be renamed, for example when Ethereal became Wireshark. If the package is an alternate version of an already existing package, use conflicts (and provides if that package is required by others). The main difference is: after syncing (-Sy) pacman immediately wants to replace an installed, 'offending' package upon encountering a package with the matching replaces anywhere in its repositories; conflicts, on the other hand, is only evaluated when actually installing the package, which is usually the desired behavior because it is less invasive.

• Packages that use prebuilt deliverables, when the sources are available, must use the -bin suffix. An exception to this is with Java. The AUR should not contain the binary tarball created by makepkg, nor should it contain the filelist.

• Please add a comment line to the top of the PKGBUILD file which contains information about the current maintainers and previous contributors, respecting the following format. Remember to disguise your email to protect against spam. Additional or unneeded lines are facultative.

If you are assuming the role of maintainer for an existing PKGBUILD, add your name to the top like this

# Maintainer: Your Name <address at domain dot tld>

If there were previous maintainers, put them as contributors. The same applies for the original submitter if this is not you. If you are a co-maintainer, add the names of the other current maintainers as well.

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