Arch User Repository

関連記事

• AUR ヘルパー
• AurJson
• AUR Trusted User ガイドライン
• PKGBUILD
• makepkg
• pacman
• .SRCINFO
• 公式リポジトリ
• Arch Build System
• パッケージの作成

Arch User Repository (AUR) はコミュニティによって運営されている Arch ユーザーのためのリポジトリです。パッケージのビルド方法が書かれたファイル (PKGBUILD) がまとめて置かれており、makepkg を使ってソースからパッケージを作り、生成したパッケージを pacman でインストールすることができます。人気のあるパッケージが [community] リポジトリに取り込まれるように、コミュニティの手で新しいパッケージを共有することを目的に AUR は作られました。このページでは AUR の使用方法を説明します。

AUR に投稿された新しいパッケージの一部は公式リポジトリに取り込まれています。AUR では、ユーザーはパッケージビルド (PKGBUILD と関連ファイル) を投稿することができます。AUR コミュニティには AUR に存在するパッケージに対して投票する機能があります。投票が十分に集まると — ライセンスに問題がなくきちんとパッケージ化されているならば — [community] リポジトリに取り込まれます (pacman や abs で直接入手できるようになります)。

はじめに

AUR ウェブインターフェイス で PKGBUILD を検索し、ダウンロードすることができます。makepkg を使って PKGBUILD からパッケージを生成することができ、pacman でインストールできます。

• base-devel パッケージグループをインストールしてください (pacman -S --needed base-devel)。
• この記事の下の方に、AUR パッケージをインストールする簡単なチュートリアルがあります。
• アップデート情報や問題を知るために AUR ウェブインターフェイス を訪れましょう。AUR で利用可能なパッケージの最新リストを見ることができます。
• よくある質問の答えはほとんど #FAQ に載っています。
• /etc/makepkg.conf を修正することで、AUR からパッケージをビルドするときに、あなたの使用しているプロセッサに最適化することができます。特にマルチコア・プロセッサを使っている場合、MAKEFLAGS を調整することでコンパイルにかかる時間を大きく短縮することができるかもしれません。また、CFLAGS の設定で GCC に対してハードウェア個別の最適化を設定できます。詳しくは makepkg.conf を見てください。

SSH 経由で AUR を使うこともできます: 利用可能なコマンドは ssh aur@aur.archlinux.org help で確認できます。

歴史

以下の情報は歴史を語るためだけに存在しています。incoming と TUR は AUR により一新されて、すでに使われていません。

当初、ftp://ftp.archlinux.org/incoming というサーバーがあり、人々は PKGBUILD やビルドに必要なファイル、ビルド済みのパッケージをアップロードしていました。パッケージメンテナが採用するまでプログラムはここに置かれたままでした。

その後、Trusted User リポジトリが誕生しました。コミュニティから許可された人のリポジトリを、誰でも使えるようにするためのリポジトリです。これを基礎として、より柔軟に使いやすくするために拡張されたものが AUR です。今でも、AUR のメンテナは TU (Trusted User) と呼ばれます。

2015年6月8日から2015年8月8日までの間に AUR はバージョン 3.5.1 から 4.0.0 に移行し、PKGBUILD を公開するのに Git リポジトリが使われるようになりました。

検索

AUR のウェブインタフェースは こちら です。スクリプト（など）によってアクセスするのに適しているインターフェースは こちら になります。

MySQL に似た構文をつかってパッケージの名前と説明を検索することができ、柔軟に検索条件を指定することが可能となっています (例えば tool like grep の代わりに tool%like%grep と検索してみてください)。% を含む文字列を検索するときは、/% とエスケープしてください。

パッケージのインストール

ノート: AUR からパッケージをインストールする公式の仕組みはありませんし今後も作られることはありません。全てのユーザーはビルドプロセスに慣れる必要があります。

AUR からパッケージをインストールする手順は比較的単純です。基本は:

1. PKGBUILD と systemd のユニットやパッチなど他の必要なファイル (ソースコードではない場合が多い) が含まれた tarball を取得します。
2. tar -xvf pkgname.tar.gz で tarball を解凍します (なるべく AUR 用に作ったフォルダで行ってください)。
3. PKGBUILD ファイルが入ったディレクトリの中で makepkg -si を実行します。自動でソースコードをダウンロード、pacman で依存関係を解決、コンパイルしてパッケージ化し、パッケージをインストールします。

必須要件

まず必要なツールがインストールされているか確かめましょう。base-devel パッケージグループは絶対に必要です。make などの (ソースコードからの) コンパイルに必要なツールが含まれています。

警告: AUR のパッケージは base-devel グループがインストールされているのを前提としているので、ビルドするにはこのグループのインストールが不可欠な場合でも、AUR パッケージはこのグループを依存のリストに挙げません。ビルドが失敗したら、このグループがインストールされているか確認しましょう。

# pacman -S --needed base-devel

次に適当なビルドディレクトリを選択します。ビルドディレクトリは単純にパッケージが作られる (または"ビルド"される) ディレクトリというだけで、どのディレクトリでもかまいません。

ビルドファイルを獲得

AUR からパッケージを入手します。検索機能 (AUR ホームページ の上部の検索ボックス) をつかってください。検索して出てきたリストからアプリケーションの名前をクリックしパッケージ情報のページを出します。説明を読んでそのパッケージをインストールすべきか決めて下さい。パッケージが最近更新されているなら、コメントも読んでおきましょう。

ビルドファイルをダウンロードする方法は複数存在します:

• "Package Details" の "Git Clone URL" に書かれている git リポジトリを複製する:

$ git clone https://aur.archlinux.org/package_name.git

リポジトリを複製する場合、git pull で簡単にパッケージを更新することができます。

• パッケージ情報のページから、右にある "パッケージアクション" 下の "スナップショットのダウンロード" リンクをクリックしてダウンロードする。圧縮ファイルがダウンロードされるので、ファイルをビルドディレクトリに移して展開してください:

$ tar -xvf package_name.tar.gz

• また、ターミナルから tarball をダウンロードすることもできます:

$ curl -L -O https://aur.archlinux.org/cgit/aur.git/snapshot/package_name.tar.gz

パッケージのビルド

まずは PKGBUILD が含まれているディレクトリに移動してください:

警告: 全てのファイルを注意してチェックしてください。新しく作られたディレクトリに cd した後、PKGBUILD と全ての .install ファイルを見て、悪意のあるコマンドが含まれていないかチェックします。PKGBUILD は makepkg で実行される bash スクリプトです: 有効な Bash 構文 やコマンドでありさえすればどんなコマンドも含むことができます、つまり作者の悪意や過失によって PKGBUILD に危険なコマンドが含まれていることがあるのです。makepkg は fakeroot を使うので (よって root で実行してはいけません)、ある程度の防護策は取られていますがそれに頼るのは危険です。疑わしいことがあれば、パッケージをビルドするのは中断してフォーラムやメーリングリストでアドバイスを求めましょう。

$ cd hoge

移動したらファイルが正しいか確認してください。例:

$ nano PKGBUILD
$ nano hoge.install

確認できたら通常ユーザーで makepkg を実行します:

$ makepkg -si

• -s/--syncdeps スイッチはビルドする前に pacman によって依存関係を自動的に解決・インストールします。
• -i/--install は作成したパッケージをインストールします。

他の便利なフラグ:

• -r/--rmdeps はビルド後に不要になった依存パッケージを削除します。ただし、パッケージを更新するときは再度依存パッケージをインストールする必要があります。
• -c/--clean はビルド時に一時的に作成されたビルドファイルを消去します。パッケージのビルドをデバッグしたい場合に有用なフラグです。

ノート: 以上の例はパッケージをビルドする手順の簡単な概略です。makepkg と ABS のページにはもっと詳しい解説が載っています、初めて使うユーザーはぜひ読んで下さい。

フィードバック

AUR ウェブインターフェイス にはコメント機能がありユーザーは PKGBUILD の作成者に提案やフィードバックをすることができます。パッチや PKGBUILD はコメントに書かないようにしてください: 鮮度がすぐ落ちて、無駄にスペースを埋めることになるからです。代わりにメンテナにメールを送るか、pastebin を使って下さい。

全ての Arch ユーザーにできる一番簡単な活動は、AUR のオンラインインターフェースを使ってお気に入りのパッケージに vote することです。全てのパッケージは TU によって [community] に取り込まれる可能性があり、vote の数が理由のひとつになります。また、投票数はみんなが気にしていることでもあります。

パッケージの共有

ユーザーは AUR の中で大事な役目をおっています、ユーザーコミュニティの参加・貢献なくしては AUR の真価は発揮されません。AUR パッケージのライフサイクルはユーザー次第であり、様々な方法での貢献が求められます。

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

パッケージを投稿する

警告: パッケージを投稿する前に Arch パッケージングスタンダードの記事や、関連記事を読むようにしてください。ルールに違反するパッケージはとくに警告もされずに削除される場合があります。

認証

AUR への書き込み権限を得るには SSH 鍵が必要になります。公開鍵の中身をアカウントのユーザープロフィールにコピーしてください。対応する秘密鍵のホストを aur.archlinux.org に設定します。例:

~/.ssh/config

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

何かが起こった時に SSH 鍵を選択的に無効化できるように、既存の SSH 鍵を使うのではなく、新しく鍵を作成することを推奨します:

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

ヒント: 入力フィールドで改行することで複数の公開鍵をプロフィールに追加することができます。

新しいパッケージの作成

まずローカルに空の Git リポジトリを作成する必要があります。リモートから適切な名前で複製してください:

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

AUR に同じ名前のパッケージが存在しない場合、以下のように警告が表示されます:

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

ノート: AUR でパッケージを削除しても git リポジトリは削除されません。そのため誰かが削除されたパッケージと同じ名前でパッケージを作成したときに中身が中になっていない場合があります。

既に git リポジトリを作成済みの場合、AUR の git リポジトリにリモートリポジトリを作成して fetch することができます:

$ git remote add remote_name ssh://aur@aur.archlinux.org/package_name.git
$ git fetch remote_name

remote_name は作成するリモートリポジトリの名前 (例: "origin") に置き換えてください。詳しくは Git#リモートの使用を参照。

最初にコミットを push すると AUR に新しいパッケージを作成されます。Git リポジトリのローカルコピーにソースファイルを追加してください。

警告: 既に公開された履歴を書き換えるのは大変難しくなります (参照: FS#45425)。別の名前・メールで AUR に push したい場合、git config user.name [...] と git config user.email [...] でユーザー名とメールアドレスを設定することができます。公開する前にコミットをよく確認しましょう。

パッケージのアップロード

リポジトリに変更を加えるときは、トップレベルディレクトリに PKGBUILD と .SRCINFO があることを確認してください。.SRCINFO ファイルは makepkg --printsrcinfo を使って作成することができます。

ノート: PKGBUILD のメタデータ (pkgver など) を変更したら毎回 .SRCINFO を再生成する必要があります。再生成しないと AUR が新しいバージョン番号を表示しません。

AUR にパッケージベースの新しいバージョンを投稿する場合、git add でステージングエリアに新しい PKGBUILD と .SRCINFO、そして時にはヘルパーファイル (.install ファイルや .patch などのローカルソースファイル) を追加し、git commit でコミットメッセージを付けてローカルツリーにコミットして、git push で変更を AUR に公開してください。

例えば、新しく作成したディレクトリに PKGBUILD を追加したら、以下のコマンドを実行することで最初のコミットを作成・送信できます:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m 'Initial import'
$ git push origin master

パッケージをアップデートするときは、PKGBUILD を編集してから AUR の Git リポジトリで変更を追跡するために以下のコマンドを実行して下さい:

$ makepkg --printsrcinfo > .SRCINFO
$ git commit -am 'Update to 1.0.0-2'
$ git push

詳しい情報は Git を見てください。

ヒント: もしあなたが .SRCINFO をコミットするのを忘れてしまって、後から .SRCINFO を追加した場合、AUR はあなたのプッシュをリジェクトします。すべてのコミットで .SRCINFO は必須だからです。git rebase を使うか、または git filter-branch と --tree-filter オプションを使うことでこの問題は解決できます。.SRCINFO にはソースパッケージのメタデータが含まれています。詳しくは .SRCINFO を見てください。

パッケージの投稿ルール

パッケージを投稿する際には、以下のルールを守りましょう:

• 投稿しようとしているパッケージが パッケージデータベース にすでに存在してないかチェックしてください。存在しているのなら、そのパッケージを投稿してはいけません。もし既にあるパッケージが壊れていたり機能していないのならバグレポート で報告してください。

上記のルールの例外として、公式パッケージと比べて機能やパッチが追加されている場合は除外されます。そのような場合は違いがわかるように pkgname を決めてください。例えば、サイドバーのパッチを適用した GNU screen のパッケージは screen-sidebar などと名前を付けます。公式パッケージと衝突しないようにするため provides=('screen') を使ってください。

• そのパッケージが AUR にすでに存在してないかチェックしてください。メンテナンスされているパッケージがあるのならば、コメントからメンテナに修正を求めることができます。パッケージが既にメンテナンスされていないのなら、作ったパッケージに差し替えることができます。パッケージを重複させないでください。
• 投稿するパッケージが皆の役に立つか考えて下さい。他の誰かがそのパッケージを使おうと考えるでしょうか？あまりにも特殊化しすぎていませんか？少なからぬ人が役に立つと思うようなパッケージであれば、投稿するのにふさわしいでしょう。

AUR と公式リポジトリは一般的に、ソフトウェアやソフトウェアに関連するコンテンツをインストールするパッケージのために存在します。該当するコンテンツとしては次のものが含まれます: 実行可能ファイル、設定ファイル、特定のソフトウェアもしくは Arch Linux ディストリビューション全体のオンライン・オフラインのドキュメント、ソフトウェアによって直接使用されるメディア。

• AUR の PKGBUILD で replaces を使うのはパッケージの名前を変更したいときです。例えば Ethereal から Wireshark に名前が変更されたときです。既存のパッケージの別バージョンとしてパッケージを作成する場合、conflicts を使ってください (他のパッケージから必要とされる場合は provides も使ってください)。conflicts と replaces は同期後 (-Sy) に pacman が即座にパッケージを置き換えるかどうかが違います。conflicts はパッケージのインストール時にしか評価されません。
• あなたがアップロードするファイルを注意して問題ないかチェックしてください。全ての投稿者は PKGBUILD を書くときに Arch パッケージングスタンダードを読まなくてはなりません。AUR の効率的な運営と一般的な目的のために重要なことです。悪い PKGBUILD で利用者を苦しませているようではあなたの評判は上がらないでしょう。
• ソースがダウンロードできる場合はバイナリを投稿するのは避けてください。AUR は makepkg によって作成されるバイナリ tarball を保存する場所ではありません。
• 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>

• もしパッケージ (やビルド・投稿プロセス) に自信がないときは、PKGBUILD を AUR メーリングリスト や AUR フォーラム に投稿して見てもらってから AUR に加えてください。
• パッケージを投稿しようとする前に経験をつみましょう。いくつかパッケージをビルドして手順を学んでから投稿してください。

パッケージのメンテナンス

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

その他

• 孤児リクエストや消去リクエストは右側の"パッケージアクション"の下にある"リクエストを送る"リンクをクリックして作成することができます。リクエストが作成されると自動的に通知メールがパッケージの現在のメンテナと aur-requests メーリングリスト に送信されます。その後 Trusted User がリクエストの承認・却下を行います。
• 孤児リクエストは通るのに2週間ほどかかることがあります。現在のメンテナにメールで連絡が行ってから、反応がないか待つためです。
• パッケージのマージも受け付けています、ユーザーはまず新しい名前でパッケージを再投稿して、古いバージョンのコメントや投票のマージをリクエストしてください。
• 消去リクエストには以下の情報が必要です:
  • パッケージ名と AUR ページの URL
  • 消去する理由、最低でも短いメモ書き
    注意: パッケージのコメント欄をパッケージの削除の理由を書くのに使うことはできません。TU ができるだけ早く行動するために、そのような情報は aur-requests メーリングリストに書かれるべきです。
  • 補足事項を加えて下さい、仮にあなたがメンテナならば、他のパッケージで提供されるようになった、パッケージ名を変えて元の管理者が認めた、など。
  • マージリクエストの場合: マージ先のパッケージベースの名前。

消去リクエストは認められないことがあります、その場合、他のパッケージメンテナに移すためにパッケージを孤児にするようアドバイスされるかもしれません。

AUR3 パッケージの Git リポジトリ

GitHub の AUR Archive には2015年8月に AUR4 に移行する前の AUR3 に存在した全てのパッケージが保存されています。

AUR メタデータ

AUR ウェブインターフェイスに情報を表示するために、AUR のバックエンドのコードでは PKGBUILD ファイルを分析して、パッケージの名前・バージョンなどの情報をサルベージしています。PKGBUILD は Bash スクリプトなので、実行することなく Bash スクリプトを正確に分析するのは難題です、そのために makepkg は Bash スクリプトで出来ています: makepkg は source ディレクティブでビルドするパッケージの PKGBUILD を読み込みます。AUR メタデータファイルはそのようなハックを取り除くために作られました。ウェブインターフェイスで間違った分析が行われないように AUR パッケージのメンテナによって使用されます。FS#25210, FS#15043, FS#16394 を参照してください。

動作の仕組み

.SRCINFO という名前のメタデータファイルをソース tarball に追加することで特定の PKGBUILD フィールドを上書きします。このファイルのフォーマットは AUR 2.1.0 のリリースアナウンスで説明されています。.SRCINFO ファイルは一行毎にパースされます。それぞれの行は key[_arch] = value という形式をとります。イコール記号の前後には半角スペースが必要で、値をクォートで囲ってはいけません。

key はフィールド名です。PKGBUILD の変数の名前に対応しています。フィールド名によっては任意でアーキテクチャの名前を語尾に付けることができます。フィールドは、以下の2つのフィールド名を先頭に、セクションに分けられています:

• pkgbase: AUR 3 から必要になったフィールドで、これがないと悪名高い “only lowercase letters are allowed” エラーが起こります (pkgbase が省略されている場合 Pacman が先の pkgname を使用します)。よく分からない場合は pkgname と同じにしてください。pkgbase セクションは一つしかありません。このセクションのフィールド値は、pkgname セクションで上書きされないかぎり継承されます。pkgname セクションに空のフィールド値がある場合、継承はキャンセルされます。
• pkgname: pkgname セクションは複数作ることができます。

以下のフィールド名は一つの値と関連付けられます:

• epoch
• pkgver: パッケージのバージョン、epoch フィールドを分けないで [epoch:]pkgver と記述することもできます
• pkgrel: Arch Linux 固有のパッケージリリース番号
• pkgdesc
• url

以下のフィールド名は複数行で繰り返し使って複数の値を追加することができます:

• license: 複数のライセンスが存在する場合、スペースで区切ります
• groups

以下のフィールド名も繰り返すことができ、任意で下線を使って、アーキテクチャを指定することができます:

• depends: 依存パッケージ、一行ごと
• makedepends
• checkdepends
• optdepends
• conflicts
• provides
• replaces
• source

他の名前のフィールドは無視されます。空の行や、ハッシュ記号 (#) で始まる行コメントも無視されます。このフォーマットは pacman/libalpm のバイナリパッケージで使われている .PKGINFO フォーマットとほぼ一致します。

pkgbuild-introspection の mksrcinfo によって PKGBUILD から .SRCINFO を作成することもできます。

AUR の翻訳

AUR ウェブインターフェイスの翻訳については AUR ソースツリーの i18n.txt を見てください。

コメント構文

AUR v4.6.0 から Python-Markdown ライブラリがサポートされています。Markdown との違いについては [1] を見てください。

FAQ

AUR とは何ですか？

AUR (Arch User Repository) は、Arch Linux コミュニティがアップロードした、アプリケーションやライブラリの PKGBUILD をコミュニティ全体で共有するスペースです。ユーザー同士でお気に入りのパッケージに投票することができ、場合によっては、[community] リポジトリに移されてバイナリ形式で Arch Linux ユーザー間に共有されます。

どのような種類のパッケージが AUR に置かれていますか？

AUR にあるパッケージはたんに"ビルドスクリプト"、つまり pacman 用にバイナリをビルドするレシピにすぎません。ほとんどの場合、上述の有用性と範囲のガイドラインを条件として、コンテンツのライセンスの問題がない限り、すべてのものが置くことを許されています。他の場合、ダウンロードにリンクできない、つまり再配布が禁止されている時は、ソースとしてファイル名だけを使うことができます。よってパッケージをビルドするには、ユーザーによってビルドディレクトリにその制限されたソースを入れておく必要があります。どちらかわからない場合は、尋ねて下さい。

TU とはどのような人ですか？

TU (Trusted User) とは、AUR と [community] リポジトリを監督するように選ばれた人のことです。彼らは [community] に入っている人気の PKGBUILD を管理していて、みんなで AUR を運営し続けています。

Arch User Repository と [community] の違いは？

Arch User Repository にはユーザーが投稿した全ての PKGBUILD が保存されており、利用するには手動で makepkg を使ってビルドしなくてはなりません。PKGBUILD に一定数の投票が入ると、パッケージは [community] リポジトリに移され TU が管理するバイナリパッケージとなり、pacman によってインストールできるようになります。

AUR のパッケージに投票するにはどうすればいいですか？

AUR のウェブサイト で登録して、パッケージのページを開いて「このパッケージに投票する」を押してください。サイトに一度登録すれば aurvote^AUR, aurvote-git^AUR, aur-auto-vote-git^AUR などを使ってコマンドラインから投票することもできます。

もしくは ssh 認証を設定して、ssh 鍵を使ってコマンドラインから直接投票することも可能です。AUR のパスワードを入力する手間を省けます。

ssh aur@aur.archlinux.org vote <PACKAGE_NAME>

システムにインストールしている AUR パッケージ全てに投票するには:

for i in $(pacman -Qqm); do echo Voting for $i; ssh aur vote $i; done

どれくらいの投票で PKGBUILD が [community] に移されますか？

通常、少なくとも 10 の投票が [community] に移されるのに必要です。しかし、TU がパッケージをサポートしたいと望んだ時は、投票数にかかわらず [community] に入ることがしばしばあります。

どうやって PKGBUILD を作るのですか？

作り方はパッケージの作成にあります。同じものをダブらせてしまわないように PKGBUILD を作る前に AUR を調べるのを忘れないようにしましょう。

[community] にあるパッケージを "pacman -S hoge" したのですがインストールされません

おそらく /etc/pacman.conf で [community] を有効にしていないのではないでしょうか。当該行をアンコメントしてください。 /etc/pacman.conf の [community] が有効になっていたのなら、pacman -Syu で pkgcache を同期してからパッケージを再度取得してみてください。

AUR の Hoge が古くなっています、どうするべきでしょうか？

第一歩として、パッケージの out-of-date フラグを立てることができます。しばらく時間がたっても out-of-date のままの場合、最良の解決策はメンテナにメールをすることです。2週間たってもメンテナから何の反応も得られないときは、孤児リクエストを作成してください。3ヶ月以上 out-of-date のままでいっこうにアップデートされる気配のないパッケージがあるのならば、孤児リクエストに加えて下さい。

ノート: VCS パッケージは pkgver 以外に変更がない場合は out-of-date とはみなすべきではありません。VCS パッケージの out-of-date フラグを立ててもメンテナはフラグを降ろしてあなたを無視することでしょう。AUR のメンテナは VCS パッケージの pkgver だけを上げるコミットをしてはいけません。

PKGBUILD を作って投稿したいと思っています。エラーがないか誰かチェックしてくれるでしょうか？

あなたの PKGBUILD を批評してもらいたいのなら、aur-general メーリングリストに投稿して、TU や AUR メンバーからの反応をみてはいかがでしょう。IRC チャンネル, #archlinux on irc.freenode.net からも助けを得ることができます。namcap を使って PKGBUILD や作られるパッケージにエラーがないかチェックすることも可能です。

AUR の Hoge を makepkg でコンパイルすることができません。どうしたらいいですか？

おそらく些細なことを見逃していると思われます。

1. makepkg でコンパイルする前に pacman -Syyu をしてみてください。あなたのシステムが最新でないことが問題かもしれません。
2. base と base-devel グループがインストール済みか確認してください。
3. ビルドプロセスをはじめる前に makepkg に "-s" オプションを使って必要な依存パッケージがインストールされているかチェックしてみてください。

まずはじめに PKGBUILD やパッケージの AUR ページのコメントを読むようにしてください。問題がカスタムした CFLAGS, LDFLAGS, MAKEFLAGS が問題を起こしているのかもしれません。その PKGBUILD が全ての人にとって壊れているかもしれません。もし自分で解決できない問題なら、AUR ページのコメントに書き込むなどしてメンテナにそれを報告してください。

ビルドの速度を速めるにはどうすればいいですか？

gcc を使って頻繁にコードをコンパイルする場合 (git や SVN パッケージなど)、ccache ("compiler cache" の略) が役にたつかもしれません。

foo と foo-git パッケージは何が違うのですか？

多くの AUR パッケージには通常バージョン ("stable") と開発バージョン ("unstable") が存在します。開発版のパッケージには大抵 "-cvs", "-svn", "-git", "-hg", "-bzr", "-darcs" などが末尾に付きます。開発版のパッケージは通常の使用には適してしませんが、新しい機能やバグフィックスが含まれていることがあります。makepkg を実行した時 -git, -svn, -hg, -bzr パッケージは最新のソースをダウンロードするので、パッケージのバージョンは必ずしも上流と合っていません。同じく、チェックサムの確認が出来ないので、git リポジトリのメンテナを信用することになります。

Arch Linux の安定化#開発中のパッケージを使わないも参照してください。

foo パッケージが AUR から消えているのはなぜですか？

ルール違反によってパッケージが削除された可能性があります。削除理由は aur-requests アーカイブ を見てください。

AUR3 に存在していたパッケージの場合、AUR4 に移行 したときにパッケージが移行されなかった可能性があります。#AUR3 パッケージの Git リポジトリを見てください。

全ての AUR パッケージのリストを入手するには？

• https://aur.archlinux.org/packages.gz
• python3-aur^AUR パッケージに含まれている aurpkglist を使用する。

参照

• AUR ウェブインターフェイス
• AUR メーリングリスト