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 などと名前を付けます。さらに、公式パッケージと衝突しないようにするために conflicts=('screen') 配列を使う必要があります。

• そのパッケージがすでに存在してないか AUR をチェックしてください。メンテナンスされているパッケージがあるのならば、コメントからメンテナに修正を求めることができます。パッケージがメンテナンスされておらず、かつメンテナが応答しないならば、必要に応じてそのパッケージを継承し、更新することができます。重複したパッケージを作成しないでください。

• 投稿するパッケージが皆の役に立つか考えて下さい。他の誰かがそのパッケージを使おうと考えるでしょうか？あまりにも特殊化しすぎていませんか？少なからぬ人が役に立つと思うようなパッケージであれば、投稿するのにふさわしいでしょう。

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

• AUR の PKGBUILD で replaces を使うのはパッケージの名前を変更したいときに限ります。例えば Ethereal から Wireshark に名前が変更されたときのようにです。既存のパッケージの別バージョンとしてパッケージを作成する場合、conflicts を使ってください (他のパッケージから必要とされる場合は provides も使ってください)。conflicts と replaces は、同期後 (-Sy) に pacman が即座にパッケージを置き換えるかどうかが違います。conflicts はパッケージのインストール時にしか評価されません。

• バージョン管理システムからビルドし、特定のバージョンに結び付かないパッケージには、(git の場合は -git といった) 適切な接尾辞を付ける必要があります。接尾辞の完全なリストは VCS パッケージガイドライン#パッケージの命名 を参照してください。

• ビルド済みの成果物を使うパッケージには、ソースコードが利用可能な場合は、-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

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

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

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

警告: あなたのコミットは、あなたのグローバルな Git の名前と email アドレスによって認証されます。コミットを、push した後に変更するのは非常に困難です (FS#45425)。別の認証情報を使って AUR に push したい場合、パッケージごとに git config user.name "..." と git config user.email "..." を使って認証情報を変更することができます。

パッケージングされたソフトウェアの新しいバージョンをリリースする際は、pkgver 変数か pkgrel 変数を更新して、すべてのユーザにアップグレードが必要であることを通知してください。typo の修正など、PKGBUILD のマイナーな変更だけの場合は、これらの値を更新しないでください。

VSC パッケージの単なる pkgver バージョンアップはコミットしないでください。それらは、上流に新しいコミットがある場合に、out-of-date とみなされません。新しいコミットをするのは、他の変更 (ビルドプロセスの変更など) が発生した場合に限ります。

PKGBUILD メタデータが変更された際 (pkgver() が更新されたときなど) は必ず .SRCINFO を再生成してください。さもないと、AUR は更新後のバージョン番号を表示しません。

パッケージをアップロード/アップデートするには、少なくとも PKGBUILD と .SRCINFO を、次に追加の新しい/変更された補助ファイル (.install ファイルや、パッチなどのローカルのソースファイル) 追加してください。そして、意味のあるコミットメッセージを付けてコミットし、最後に変更を AUR にプッシュしてください。

例:

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

ノート:

• .SRCINFO が最初のコミットに含まれていなかった場合、--root で rebase するかツリーをフィルタリングして追加してください。そうすれば、AUR は初期のプッシュを受け入れます。
• AUR は、master ブランチへのプッシュのみを許可します。ローカルのブランチに他の名前をつけている場合、名前を変更し、再びプッシュしてください。

ヒント: 作業ディレクトリとコミットもを可能な限り綺麗に保つには、すべてのファイルを除外する gitignore(5) を作成し、必要に応じてファイルを force-add してください。

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

• 他のユーザーからのコメントやフィードバックをチェックして、ときには提案を汲み上げるようにしましょう。学習過程だと考えて下さい。
• パッケージを更新する度にバージョン番号を含むコメントを投稿するのはやめてください。コメント欄は、上記で説明したような意味ある内容のために使って下さい。
• パッケージを投稿したらそのまま放置するのはやめてください。アップデートをチェックし、PKGBUILD を修正してパッケージをメンテナンスするのがメンテナの仕事です。
• 何らかの理由でパッケージのメンテナンスが続けられない場合は、AUR ウェブインタフェースでパッケージを disown するか、メーリングリストにメッセージを投稿してください。AUR パッケージのメンテナがパッケージを放棄すると、パッケージは"孤児"パッケージになります。
• 自動化はメンテナにとって価値のあるツールですが、手動介入を置き換えることはできません (例: プロジェクトは、たとえ「マイナー」リリースであっても、ライセンスの変更、依存関係の追加/削除、その他の重要な変更を行う可能性があります)。自動的に作成された PKGBUILD の更新は自己責任で使用してください。機能不全に陥ったアカウントやそのパッケージは予告もなく削除される場合があります。

リクエスト

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

削除

AUR から pkgbase を削除するリクエストです。削除の理由とそれの裏付けとなる詳細 (他のパッケージによってパッケージが提供されている、あなた自身がメンテナである、パッケージの名称が変更された、元の所有者が同意したなど) を説明する短いノートが必要です。

ノート:

• パッケージが削除対象である理由をコメント欄だけで説明するのは不十分です。TU がアクションを取ったときにすぐそのような情報が入手できる唯一の場所は aur-requests メーリングリストだけです。
• 削除リクエストが却下される可能性もあります。この場合、あなたがそのメンテナであるならば、おそらく、パッケージを放棄して他のメンテナに引き取れるようにするようアドバイスを受けるでしょう。
• パッケージが「削除」された後も、そのパッケージの git リポジトリはクローンできる状態のままになります。

マージ

pkgbase の削除を行い、その投票数とコメントを他の pkgbase に移動させるリクエストです。マージ先のパッケージの名前が必要です。

ノート: これは 'git merge' や GitLab のマージリクエストとは関係ありません。

孤児

pkgbase を放棄させるリクエストです。現在のメンテナが応答しない場合、このリクエストは2週間後に受理されます。例外は、パッケージに out-of-date フラグが少なくとも180日間建てられている場合です。この場合、孤児リクエストは自動的に受理されます。

翻訳ステータス: このページは en:AUR submission guidelines の翻訳バージョンです。最後の翻訳日は 2023-05-19 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。