「AUR 投稿ガイドライン」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(同期)
 
(2人の利用者による、間の5版が非表示)
12行目: 12行目:
 
{{Related articles end}}
 
{{Related articles end}}
   
ユーザーは [[Arch User Repository]] を使って PKGBUILD を'''シェア'''することができます。AUR にはバイナリパッケージはありませんが、他のユーザがダウンロードできる PKGBUILD をアップロードできます。これらの PKGBUILD は完全に非公式なものであり、徹底して管理されてはいないので、自己責任において使うことになります。
+
ユーザーは [[Arch User Repository]] を使って [[PKGBUILD]] スクリプトを'''シェア'''することができます。AUR にはバイナリパッケージはありませんが、他のユーザがダウンロードできる PKGBUILD をアップロードできます。これらの PKGBUILD は完全に非公式なものであり、徹底して管理されてはいないので、自己責任において使うことになります。
   
 
== パッケージを投稿する ==
 
== パッケージを投稿する ==
26行目: 26行目:
 
* 投稿する PKGBUILD は、いかなる状況であっても、'''公式''' バイナリ '''リポジトリ'''に '''すでに存在する''' アプリケーションをビルドするものであってはいけません。[https://archlinux.org/packages/ 公式パッケージデータベース]でパッケージをチェックしてください。そのパッケージの任意のバージョンが存在する場合、そのパッケージを投稿'''しないでください'''。公式のパッケージが out-of-date である場合、そのフラグを立ててください。公式のパッケージが壊れている、あるいは機能不足である場合、[https://bugs.archlinux.org/ バグレポート]を提出してください。
 
* 投稿する PKGBUILD は、いかなる状況であっても、'''公式''' バイナリ '''リポジトリ'''に '''すでに存在する''' アプリケーションをビルドするものであってはいけません。[https://archlinux.org/packages/ 公式パッケージデータベース]でパッケージをチェックしてください。そのパッケージの任意のバージョンが存在する場合、そのパッケージを投稿'''しないでください'''。公式のパッケージが out-of-date である場合、そのフラグを立ててください。公式のパッケージが壊れている、あるいは機能不足である場合、[https://bugs.archlinux.org/ バグレポート]を提出してください。
   
:この厳格な規則の'''例外'''は、パッケージが公式のパッケージと比べて '''追加の機能''' が有効化されていたり '''パッチ''' が当てられていたりする場合のみです。そのような場合は、{{ic|pkgname}} が、その違いを表すように異なっているべきです。例えば、サイドバーのパッチを適用した GNU screen のパッケージは {{ic|screen-sidebar}} などと名前を付けます。さらに、公式パッケージと衝突しないようにするため {{ic|1=provides=('screen')}} を使ってください
+
:この厳格な規則の'''例外'''は、パッケージが公式のパッケージと比べて '''追加の機能''' が有効化されていたり '''パッチ''' が当てられていたりする場合のみです。そのような場合は、{{ic|pkgname}} が、その違いを表すように異なっているべきです。例えば、サイドバーのパッチを適用した GNU screen のパッケージは {{ic|screen-sidebar}} などと名前を付けます。さらに、公式パッケージと衝突しないようにするため {{ic|1=conflicts=('screen')}} 配列を使う必要があります
   
 
* そのパッケージが'''すでに存在してないか''' '''AUR をチェックしてください'''。メンテナンスされているパッケージがあるのならば、コメントからメンテナに修正を求めることができます。パッケージがメンテナンスされておらず、かつメンテナが応答しないならば、必要に応じてそのパッケージを継承し、更新することができます。重複したパッケージを作成しないでください。
 
* そのパッケージが'''すでに存在してないか''' '''AUR をチェックしてください'''。メンテナンスされているパッケージがあるのならば、コメントからメンテナに修正を求めることができます。パッケージがメンテナンスされておらず、かつメンテナが応答しないならば、必要に応じてそのパッケージを継承し、更新することができます。重複したパッケージを作成しないでください。
34行目: 34行目:
 
:AUR と公式リポジトリは、一般的にソフトウェアやソフトウェアに関連するコンテンツをインストールするパッケージのために存在します。該当するコンテンツとしては次のものが含まれます: 実行可能ファイル、設定ファイル、特定のソフトウェアもしくは Arch Linux ディストリビューション全体のオンライン・オフラインのドキュメント、ソフトウェアによって直接使用されるメディア。
 
:AUR と公式リポジトリは、一般的にソフトウェアやソフトウェアに関連するコンテンツをインストールするパッケージのために存在します。該当するコンテンツとしては次のものが含まれます: 実行可能ファイル、設定ファイル、特定のソフトウェアもしくは Arch Linux ディストリビューション全体のオンライン・オフラインのドキュメント、ソフトウェアによって直接使用されるメディア。
   
* AUR の PKGBUILD で {{ic|replaces}} を使うのはパッケージの名前を変更したいときす。例えば ''Ethereal'' から ''Wireshark'' に名前が変更されたときのようにです。'''既存のパッケージの別バージョン'''としてパッケージを作成する場合、{{ic|conflicts}} を使ってください (他のパッケージから必要とされる場合は {{ic|provides}} も使ってください)。{{ic|conflicts}} と {{ic|replaces}} は、同期後 (-Sy) に pacman が即座にパッケージを置き換えるかどうかが違います。{{ic|conflicts}} はパッケージのインストール時にしか評価されません。
+
* AUR の PKGBUILD で {{ic|replaces}} を使うのはパッケージの名前を変更したいときに限ります。例えば ''Ethereal'' から ''Wireshark'' に名前が変更されたときのようにです。'''既存のパッケージの別バージョン'''としてパッケージを作成する場合、{{ic|conflicts}} を使ってください (他のパッケージから必要とされる場合は {{ic|provides}} も使ってください)。{{ic|conflicts}} と {{ic|replaces}} は、同期後 (-Sy) に pacman が即座にパッケージを置き換えるかどうかが違います。{{ic|conflicts}} はパッケージのインストール時にしか評価されません。
  +
  +
* バージョン管理システムからビルドし、特定のバージョンに結び付かないパッケージには、(git の場合は {{ic|-git}} といった) 適切な接尾辞を付ける必要があります。接尾辞の完全なリストは [[VCS パッケージガイドライン#パッケージの命名]] を参照してください。
   
 
* '''ビルド済み'''の[[Wikipedia:ja:成果物|成果物]]を使うパッケージには、ソースコードが利用可能な場合は、{{ic|-bin}} サフィックスを付けなければなりません。この規則の例外として、[[Java パッケージガイドライン#パッケージング|Java]] を使う場合です。AUR には、makepkg によって作成されたバイナリ tarball や、filelist が含まれているべきではありません。
 
* '''ビルド済み'''の[[Wikipedia:ja:成果物|成果物]]を使うパッケージには、ソースコードが利用可能な場合は、{{ic|-bin}} サフィックスを付けなければなりません。この規則の例外として、[[Java パッケージガイドライン#パッケージング|Java]] を使う場合です。AUR には、makepkg によって作成されたバイナリ tarball や、filelist が含まれているべきではありません。
   
  +
* 特定のバージョンを用いてソースからビルドするパッケージには、接尾辞を用いません。
* {{ic|PKGBUILD}} ファイルのトップには、現在の '''メンテな''' と以前の '''貢献者''' の情報を含む '''コメント行''' を、以下の形式に沿って追加してください。スパムから身を守るためにメールアドレスをぼかしましょう。追加/不必要な行は任意です。
 
  +
  +
* {{ic|PKGBUILD}} ファイルのトップには、現在の '''メンテナ''' と以前の '''貢献者''' の情報を含む '''コメント行''' を、以下の形式に沿って追加してください。スパムから身を守るためにメールアドレスをぼかしましょう。追加/不必要な行は任意です。
  +
  +
{{Note|電子メールのアドレスに関して難読化を行うと人々があなたに連絡を行うことを困難にしてしまいます。}}
  +
 
:もしあなたが既存の PKGBUILD のメンテナの役割を引き受けるのであれば、以下のようにあなたの名前をトップに追加してください。
 
:もしあなたが既存の PKGBUILD のメンテナの役割を引き受けるのであれば、以下のようにあなたの名前をトップに追加してください。
 
:{{bc|<nowiki>
 
:{{bc|<nowiki>
81行目: 88行目:
 
$ git remote add ''label'' <nowiki>ssh://</nowiki>aur@aur.archlinux.org/''pkgbase''.git
 
$ git remote add ''label'' <nowiki>ssh://</nowiki>aur@aur.archlinux.org/''pkgbase''.git
   
次に、AUR 内にこのリモートリポジトリを[[Git#リモートの使用|フェッチ]]して初期化してください。
+
次に、このリモートリポジトリを[[Git#リモートの使用|フェッチ]]して初期化してください。
   
 
{{Note|{{ic|''pkgbase''}} が削除されたパッケージとマッチする場合、衝突を解決するために [https://git-scm.com/docs/git-pull#git-pull---rebasefalsetruemergespreserveinteractive pull、rebase] してください。}}
 
{{Note|{{ic|''pkgbase''}} が削除されたパッケージとマッチする場合、衝突を解決するために [https://git-scm.com/docs/git-pull#git-pull---rebasefalsetruemergespreserveinteractive pull、rebase] してください。}}
87行目: 94行目:
 
=== 新しいパッケージコンテンツを公開する ===
 
=== 新しいパッケージコンテンツを公開する ===
   
{{Warning|Your commits will be authored with your [[Git#Configuration|global Git name and email address]]. It is very difficult to change commits after pushing them ({{Bug|45425}}). If you want to push to the AUR under different credentials, you can change them per package with {{ic|git config user.name "..."}} and {{ic|git config user.email "..."}}.}}
+
{{Warning|あなたのコミットは、あなたの[[Git#設定|グローバルな Git の名前と email アドレス]]によって認証されます。コミットを、push した後に変更するのは非常に困難です ({{Bug|45425}})。別の認証情報を使って AUR push したい場合、パッケージごとに {{ic|git config user.name "..."}} {{ic|git config user.email "..."}} を使って認証情報を変更することができます。}}
   
  +
パッケージングされたソフトウェアの新しいバージョンをリリースする際は、[[pkgver]] 変数か [[PKGBUILD#pkgrel|pkgrel]] 変数を更新して、すべてのユーザにアップグレードが必要であることを通知してください。typo の修正など、[[PKGBUILD]] のマイナーな変更だけの場合は、これらの値を更新しないでください。
When releasing a new version of the packaged software, update the [[pkgver]] or [[PKGBUILD#pkgrel|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.
 
   
  +
[[VCS パッケージガイドライン|VSC パッケージ]]の単なる {{ic|pkgver}} バージョンアップはコミットしないでください。それらは、上流に新しいコミットがある場合に、out-of-date とみなされません。新しいコミットをするのは、他の変更 (ビルドプロセスの変更など) が発生した場合に限ります。
Do not commit mere {{ic|pkgver}} bumps for [[VCS package guidelines|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.
 
   
  +
{{ic|PKGBUILD}} メタデータが変更された際 ({{ic|pkgver()}} が更新されたときなど) は必ず [[.SRCINFO]] を再生成してください。さもないと、AUR は更新後のバージョン番号を表示しません。
Be sure to regenerate [[.SRCINFO]] whenever {{ic|PKGBUILD}} metadata changes, such as {{ic|pkgver()}} updates; otherwise the AUR will not show updated version numbers.
 
   
  +
パッケージをアップロード/アップデートするには、''少なくとも'' {{ic|PKGBUILD}} と {{ic|.SRCINFO}} を、次に追加の新しい/変更された補助ファイル ([[PKGBUILD#install|''.install'']] ファイルや、[[パッケージにパッチを適用|パッチ]]などの[[PKGBUILD#source|ローカルのソースファイル]]) [[Git#ステージング|追加]]してください。そして、意味のあるコミットメッセージを付けて[[Git#変更をコミット|コミット]]し、最後に変更を AUR に[[Git#リポジトリにプッシュ|プッシュ]]してください。
To upload or update a package, [[Git#Staging changes|add]] ''at least'' {{ic|PKGBUILD}} and {{ic|.SRCINFO}}, then any additional new or modified helper files (such as [[PKGBUILD#install|''.install'']] files or [[PKGBUILD#source|local source files]] such as [[Patching packages|patches]]), [[Git#Committing changes|commit]] with a meaningful commit message, and finally [[Git#Push to a repository|push]] the changes to the AUR.
 
   
  +
例:
For example:
 
   
 
$ makepkg --printsrcinfo > .SRCINFO
 
$ makepkg --printsrcinfo > .SRCINFO
105行目: 112行目:
   
 
{{Note|
 
{{Note|
* If {{ic|.SRCINFO}} was not included in your first commit, add it by [https://git-scm.com/docs/git-rebase#git-rebase---root rebasing with --root] or [https://git-scm.com/docs/git-filter-branch#git-filter-branch---tree-filterltcommandgt filtering the tree] so the AUR will permit your initial push.
+
* {{ic|.SRCINFO}} が最初のコミットに含まれていなかった場合、[https://git-scm.com/docs/git-rebase#git-rebase---root --root rebase する]か[https://git-scm.com/docs/git-filter-branch#git-filter-branch---tree-filterltcommandgt ツリーをフィルタリング]して追加してください。そうすれば、AUR は初期のプッシュを受け入れます。
* The AUR only allows pushes to the {{ic|master}} branch. If the local branch is named something else, [https://git-scm.com/docs/git-branch rename it] and push again.
+
* AUR は、{{ic|master}} ブランチへのプッシュのみを許可します。ローカルのブランチに他の名前をつけている場合、[https://git-scm.com/docs/git-branch 名前を変更し]、再びプッシュしてください。
 
}}
 
}}
   
  +
{{Tip|作業ディレクトリとコミットもを可能な限り綺麗に保つには、すべてのファイルを除外する {{man|5|gitignore}} を作成し、必要に応じてファイルを force-add してください。}}
{{Tip|To keep the working directory and commits as clean as possible, create a {{man|5|gitignore}} that excludes all files and force-add files as needed.}}
 
   
 
== パッケージをメンテナンスする ==
 
== パッケージをメンテナンスする ==
117行目: 124行目:
 
* パッケージを投稿したらそのまま放置するのはやめてください。アップデートをチェックし、PKGBUILD を修正してパッケージをメンテナンスするのがメンテナの仕事です。
 
* パッケージを投稿したらそのまま放置するのはやめてください。アップデートをチェックし、PKGBUILD を修正してパッケージをメンテナンスするのがメンテナの仕事です。
 
* 何らかの理由でパッケージのメンテナンスが続けられない場合は、AUR ウェブインタフェースでパッケージを {{ic|disown}} するか、メーリングリストにメッセージを投稿してください。AUR パッケージのメンテナがパッケージを放棄すると、パッケージは[https://aur.archlinux.org/packages/?SB=n&do_Orphans=Orphans "孤児"]パッケージになります。
 
* 何らかの理由でパッケージのメンテナンスが続けられない場合は、AUR ウェブインタフェースでパッケージを {{ic|disown}} するか、メーリングリストにメッセージを投稿してください。AUR パッケージのメンテナがパッケージを放棄すると、パッケージは[https://aur.archlinux.org/packages/?SB=n&do_Orphans=Orphans "孤児"]パッケージになります。
  +
* 自動化はメンテナにとって価値のあるツールですが、[https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/AYISVT7SOB444HXHIF2CKA2TIHBESH2D/ 手動介入]を置き換えることはできません (例: プロジェクトは、たとえ「マイナー」リリースであっても、ライセンスの変更、依存関係の追加/削除、その他の重要な変更を行う可能性があります)。自動的に作成された PKGBUILD の更新は自己責任で使用してください。機能不全に陥ったアカウントやそのパッケージは予告もなく削除される場合があります。
   
 
== リクエスト ==
 
== リクエスト ==
   
孤児リクエスト、消去リクエスト、マージリクエストは右側の "パッケージアクション" の下にある "リクエストを送" リンクをクリックして作成することができます。リクエストが作成されると自動的に通知メールがパッケージの現在のメンテナと [https://lists.archlinux.org/mailman3/lists/aur-requests.lists.archlinux.org/ aur-requests メーリングリスト] に送信されます。その後 [[Trusted Users]] がリクエストの承認・却下を行います。
+
削除リクエスト、マージリクエスト、孤児リクエストは右側の "パッケージアクション" の下にある "リクエストを送" リンクをクリックして作成することができます。リクエストが作成されると通知メールがパッケージの現在のメンテナと [https://lists.archlinux.org/mailman3/lists/aur-requests.lists.archlinux.org/ aur-requests メーリングリスト] に送信されます。その後 [[Trusted Users]] がリクエストの承認・却下を行います。
  +
* 孤児リクエストは、現在のメンテナが応答しない場合、通るのに2週間掛かります。例外は、180 日間以上パッケージに out-of-date フラグが立てられている場合です。この場合、孤児リクエストは自動的に受理されます。
 
  +
=== 削除 ===
* マージリクエストは、パッケージベースを削除し、票とコメントを他のパッケージベースに転送します。マージ先のパッケージベースの名前が必要です。これは 'git merge' や GitLab のマージリクエストとは関係ないことに注意してください。
 
  +
* 消去リクエストには以下の情報が必要です:
 
  +
AUR から {{ic|''pkgbase''}} を削除するリクエストです。削除の理由とそれの裏付けとなる詳細 (他のパッケージによってパッケージが提供されている、あなた自身がメンテナである、パッケージの名称が変更された、元の所有者が同意したなど) を説明する短いノートが必要です。
** 削除の理由を説明する短いノート。パッケージのコメント欄は、パッケージを削除する理由を説明するのに十分でないことに注意してください。TU が行動を起こしてすぐにそのような情報を入手できる場所は aur-requests メーリングリストだけだからです。
 
  +
{{Note|
** 補足事項を加えて下さい。仮にあなたがメンテナならば、他のパッケージで提供されるようになった、パッケージ名を変えて元の管理者が認めた、など。
 
  +
* パッケージが削除対象である理由をコメント欄だけで説明するのは不十分です。TU がアクションを取ったときにすぐそのような情報が入手できる唯一の場所は aur-requests メーリングリストだけです。
** パッケージが削除されたあとも、その Git リポジトリは AUR で利用可能なままです。
 
  +
* 削除リクエストが却下される可能性もあります。この場合、あなたがそのメンテナであるならば、おそらく、パッケージを放棄して他のメンテナに引き取れるようにするようアドバイスを受けるでしょう。
  +
* パッケージが「削除」された後も、そのパッケージの [[git]] リポジトリは[[Arch User Repository#ビルドファイルを取得する|クローン]]できる状態のままになります。}}
  +
  +
=== マージ ===
  +
  +
{{ic|''pkgbase''}} の削除を行い、その投票数とコメントを他の {{ic|''pkgbase''}} に移動させるリクエストです。マージ先のパッケージの名前が必要です。
  +
{{Note|これは 'git merge' や GitLab のマージリクエストとは関係ありません。}}
  +
  +
=== 孤児 ===
  +
  +
{{ic|''pkgbase''}} を放棄させるリクエストです。現在のメンテナが応答しない場合、このリクエストは2週間後に受理されます。例外は、パッケージに out-of-date フラグが少なくとも180日間建てられている場合です。この場合、孤児リクエストは自動的に受理されます。
  +
  +
{{TranslationStatus|AUR submission guidelines|2023-05-19|777767}}

2023年5月19日 (金) 15:07時点における最新版

関連記事

ユーザーは 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 も使ってください)。conflictsreplaces は、同期後 (-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 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。