Arch User Repository

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

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

はじめに

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

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

歴史

以下の情報は歴史を語るためだけに存在しています。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 からパッケージをインストールする手順は比較的単純です。基本は:

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

必須要件

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

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

# pacman -S --needed base-devel

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

ビルドファイルを獲得

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

必要なビルドファイルをダウンロードします。パッケージ情報のページから、右にある "パッケージアクション" 下の "スナップショットのダウンロード" リンクをクリックしてダウンロードします。ダウンロードしたファイルはビルドディレクトリに移してください。ここでは、hoge.tar.gz という名前のファイルということにします (標準フォーマットは pkgname.tar.gz です)。

また、ターミナルから tarball をダウンロードすることもできます。まずビルドディレクトリに移動してください:

$ cd ~/builds
$ curl -L -O https://aur.archlinux.org/cgit/aur.git/snapshot/hoge.tar.gz

パッケージのビルド

tarball を解凍します。ビルドディレクトリに cd してビルドファイルを解凍してください。

$ cd ~/builds
$ tar -xvf hoge.tar.gz

ビルドディレクトリの中に hoge という名前の新しいディレクトリが作られるはずです。

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

$ cd hoge
$ nano PKGBUILD
$ nano hoge.install

パッケージを作ります。ファイルが正しいか確認したあと、ビルドディレクトリにおいて通常ユーザーで makepkg を実行します:

$ makepkg -sri

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

ノート: 以上の例はパッケージをビルドする手順の簡単な概略です。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 鍵が必要になります。

公開鍵 .ssh/foo.pub の中身をアカウントのユーザープロフィールにコピーしてください。何かが起こった時に SSH 鍵を選択的に無効化できるように、既存の SSH 鍵を使うのではなく、新しく鍵を作成することを推奨します。

パッケージをアップロードするには、Git リポジトリを適当な名前で複製してください:

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

Git リポジトリのローカルコピーにソースファイルを追加することが可能です。リポジトリに変更を加えるときは、トップレベルディレクトリに PKGBUILD と .SRCINFO があることを確認してください。.SRCINFO ファイルは mksrcinfo (pkgbuild-introspection に含まれています) を使って作成することができます。

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

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

$ mksrcinfo
$ git add PKGBUILD .SRCINFO
$ git commit -m 'Initial import'
$ git push origin master

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

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

$ mksrcinfo
$ git commit -am 'Update to 1.0.0-2'
$ git push

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

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

ノート: .SRCINFO にはソースパッケージのメタデータが含まれています。詳しくは #AUR メタデータを見て下さい。

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

そのパッケージがパッケージデータベースにすでに存在してないかチェックしてください。存在しているのなら、そのパッケージを投稿してはいけません。もし既にあるパッケージが壊れていたり機能していないのならバグレポートで報告してください。
そのパッケージが AUR にすでに存在してないかチェックしてください。メンテナンスされているパッケージがあるのならば、コメントからメンテナに修正を求めることができます。パッケージが既にメンテナンスされていないのなら、作ったパッケージに差し替えることができます。パッケージを重複させないでください。
あなたがアップロードするファイルを注意して問題ないかチェックしてください。全ての投稿者は PKGBUILD を書くときに Arch パッケージングスタンダードを読まなくてはなりません。AUR の効率的な運営と一般的な目的のために重要なことです。悪い PKGBUILD で利用者を苦しませているようではあなたの評判や名誉はうまれないでしょう。
バイナリを含んでいたり全く不十分のパッケージは警告なしで削除されることがあります。
もしパッケージ (やビルド・投稿プロセス) に自信がないときは、PKGBUILD を AUR メーリングリストや AUR フォーラムに投稿して見てもらってから AUR に加えてください。
そのパッケージが役に立つか考えて下さい。他の誰かがそのパッケージを使おうと考えるでしょうか？あまりにも特殊化しすぎていませんか？そのパッケージが役に立つと一般的な人が思うようなものであれば、投稿するのにふさわしいでしょう。
AUR と公式リポジトリは一般的に、ソフトウェアやソフトウェアに関連するコンテンツをインストールするパッケージのためにあります、それには以下のものが含まれます: 実行可能ファイル、設定ファイル、特定のソフトウェアもしくは Arch Linux ディストリビューション全体のオンライン・オフラインのドキュメント、ソフトウェアによって直接使用されるメディア。
パッケージを投稿しようとする前に経験をつみましょう。いくつかパッケージをビルドして手順を学んでから投稿してください。
'package' という名前のファイルを含んだ package.tar.gz を投稿するとエラーが表示されます: 'Could not change to directory /home/aur/unsupported/package/package'。これを修正するには、ファイルの 'package' という名前を何か他の名前に変えてください、例えば、'package.rc'。pkg ディレクトリにインストールされたときに名前を 'package' に戻すことができます。Arch パッケージングスタンダード#パッケージを AUR に投稿するも読んで下さい。

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

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

その他

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

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

Git リポジトリ

2015年8月8日、Git バックエンドへの移行に従ってメンテナンスがされていないパッケージは AUR から削除されました。

旧 AUR の Git リポジトリは git://pkgbuild.com/aur-mirror.git にあります。現在はリードオンリーになっています。commit 履歴が必要ない場合は、--depth=1 オプションを使うことで高速に複製することができます:

$ git clone --depth=1 git://pkgbuild.com/aur-mirror.git

http://pkgbuild.com/git/aur-mirror.git/tree/<packagename> に直接アクセスすることもできます。ウェブブラウザで http://pkgbuild.com/git/aur-mirror.git/tree をロードしようとすると大量の時間がかかります。

詳しくは: ウェブインターフェイス, フォーラムスレッド。

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 ソースツリーの TRANSLATING を見て下さい。

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 によってインストールできるようになります。

どれくらいの投票で 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 のままでいっこうにアップデートされる気配のないパッケージがあるのならば、孤児リクエストに加えて下さい。

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

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

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

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

makepkg でコンパイルする前に pacman -Syyu をしてみてください。あなたのシステムが最新でないことが問題かもしれません。
"base" と "base-devel" グループがインストール済みか確認してください。
ビルドプロセスをはじめる前に 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 の安定化#開発中のパッケージを使わないも参照してください。