VCS パッケージガイドライン

提供: ArchWiki
2023年10月29日 (日) 17:49時点におけるKgx (トーク | 投稿記録)による版 (→‎Git サブモジュール: 翻訳を修正)
ナビゲーションに移動 検索に移動
パッケージ作成ガイドライン

32ビット – CLR – クロス – Eclipse – Electron – Free Pascal – GNOME – Go – Haskell – Java – KDE – カーネル – Lisp – MinGW – Node.js – ノンフリー – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – ウェブ – Wine

バージョン管理システムは通常の安定版のパッケージと最新の (trunk) 開発版のブランチ、どちらのソースコードの取得にも使うことができます。この記事では両方のケースを説明しています。

プロトタイプ

pacman パッケージに含まれている PKGBUILD のプロトタイプだけを使うようにしてください (/usr/share/pacman の PKGBUILD-split.proto, PKGBUILD-vcs.proto, PKGBUILD.proto)。

ガイドライン

パッケージの命名

pkgname の末尾に -cvs, -svn, -hg, -darcs, -bzr, -git などを付けて下さい。パッケージが特定のリリースを取得する場合は別です。

バージョン管理

  • 依存関係, URL, ソースなどの変更を行なったことで作られるパッケージが異なるようになった時は pkgrel の値を増やして下さい。pkgver を変える必要はありません。
ヒント: --holdver を使用すると、makepkg による pkgver の更新を防ぐことができます (makepkg(8) を参照)
  • --holdver を使うことで makepkg が pkgver を更新するのを止めることができます (参照: makepkg(8))

競合と依存関係

  • * パッケージが競合するものと提供するものを含めます (例: fluxbox-gitAUR: conflicts=('fluxbox') および provides=('fluxbox'))
  • replaces=() は通常、不要な問題を引き起こすため、回避する必要があります。
  • 適切な VCS ツールを makedepends=() (cvs、subversion、git、...) に含めます。

認証とセキュリティ

  • cvsroot を使用する場合は、空のパスワードまたは anonymous:password@ (必要な場合) を入力する手間を避けるために、anonymous@ ではなく anonymous:@ を使用してください。
  • ソースは静的ではないため、'SKIP' を追加して、sha256sums=() のチェックサムをスキップします。

VCS ソース

ノート: Pacman 4.1 は以下の VCS ソースをサポートしています: bzr, git, hg, svn。サポートされている VCS の一覧は man PKGBUILD の fragment セクションや PKGBUILD(5) を見て下さい。

pacman 4.1 から、VCS ソースは source=() に指定することになり他のソースと同じように扱われるようになりました。makepkg はリポジトリを $SRCDEST (makepkg.conf(5) の設定がない場合は $startdir と同じ) に複製・チェックアウト・ブランチして $srcdir にコピーします (それぞれの VCS に合わせた方法を使います)。ローカルリポジトリは変更がされないので、-build ディレクトリを作る必要はありません。

VCS の source=() の一般的なフォーマットは: 

source=('[folder::][vcs+]url[#fragment]')
  • folder (任意) はデフォルトのリポジトリ名を (trunk など) 無関係な名前から他の名前に変更するため、もしくは以前のソースを維持するために使われます。
  • vcs+ は VCS のタイプを表さない URL で必要です (例: git+http://some_repo)。
  • url はリモートやローカルのリポジトリの URL です。
  • #fragment (任意) は特定のブランチやコミットを pull するのに必要です。各 VCS で使えるフラグメントの詳細は man PKGBUILD を見て下さい。

Git の source の例: 

source=('project_name::git+http://project_url#branch=project_branch')
警告: folder フィールドでは pkgver 変数を使用しないようにしてください。変数は pkgver() 関数呼び出し中に変更される可能性があり、使用できなくなります。後続の機能で作成されたフォルダーにアクセスします。

関数 pkgver()

pkgver() 関数を使うことで pkgver を自動で更新することが可能です。これによって pkgver をより良くコントロールすることが出来るようになります。メンテナは pkgver を意味あるものに扱うべきです。

次のバージョンフォーマットが推奨されています: RELEASE.rREVISION。REVISION はソースツリーの変更毎に増える番号です (VCS のリビジョンと同じ)。最新の VCS タグは RELEASE に使うことができます。公開リリースやリポジトリのタグがない場合、ゼロをリリース番号に使ったり RELEASE を完全に省いて rREVISION のようにバージョンを使って下さい。公開リリースが存在してリポジトリにタグがないときは開発者はプロジェクトファイルのパースなどによってリリースバージョンを取得します。

リビジョン番号の区分け (REVISION の前の "r") は重要です。開発元が初めてリリースを行うことを決めたり、別のバージョン方式によるバージョンを付けるようになった場合に問題を避けることができます。例えばリビジョン "455" で、上流がバージョン 0.1 をリリースした場合、リビジョンの区分けをしていれば問題なくバージョンアップが認識されます (0.1.r456 > r454)。区分けがないとバージョンアップと認識されません (0.1.456 < 454)。

以下は意図した出力を行うサンプルです:

Git

最後のコミットの注釈付きタグを使う: 

pkgver() {
  cd "$pkgname"
  git describe --long | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}
2.0.r6.ga17a017

最後のコミットの注釈が付かないタグを使う: 

pkgver() {
  cd "$pkgname"
  git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}
0.71.r115.gd95ee07

git タグにダッシュが含まれていない場合、sed はもっとシンプルにできます: sed 's/-/.r/;s/-/./'。

タグに v やプロジェクト名などが付いている場合、取り除きます: 

pkgver() {
  cd "$pkgname"
  # cutting off 'foo-' prefix that presents in the git tag
  git describe --long | sed 's/^foo-//;s/\([^-]*-g\)/r\1/;s/-/./g'
}
6.1.r3.gd77e105

タグが存在しない場合、最初から数えたリビジョンの数を使ってください: 

pkgver() {
  cd "$pkgname"
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}
r1142.a17a017

バージョンとコミット/リビジョン番号のみ (SHA1 は省かれます。ただし、バージョンを忘れると実際のリビジョンがわからなくなります): 

git describe --long | sed -r 's/-([0-9,a-g,A-G]{7}.*)//' | sed 's/-/./'

両方を組み合わせて、タグが最初に付かないリポジトリに対応することもできます (bashism を使用): 

pkgver() {
  cd "$pkgname"
  ( set -o pipefail
    git describe --long 2>/dev/null | sed 's/\([^-]*-g\)/r\1/;s/-/./g' ||
    printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
  )
}
0.9.9.r27.g2b039da  # if tags exist
r1581.2b039da       # else fallback

Subversion

pkgver() {
  cd "$pkgname"
  local ver="$(svnversion)"
  printf "r%s" "${ver//[[:alpha:]]}"
}
r8546
ノート: プロジェクトにリリースがある場合は 0. の代わりにそれを使って下さい。

Mercurial

pkgver() {
  cd "$pkgname"
  printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)"
}
r2813.75881cc5391e

Bazaar

pkgver() {
  cd "$pkgname"
  printf "r%s" "$(bzr revno)"
}
r830

Fallback

リポジトリから pkgver が全く得られない場合は、現在の日付を使うことができます: 

pkgver() {
  date +%Y%m%d
}
20130408

ソースツリーの状態を一意に示しているのではないので、出来る限り使わないで下さい。

ヒントとテクニック

Git サブモジュール

Git のサブモジュールは、注意が必要です。サブモジュール自身の URL を直接 sources 配列に追加し、prepare() の中でそれらを参照するというものです

下流プロジェクトの開発者は、上流モジュールのリポジトリと同じ名前のサブモジュールを作成することはできません。git サブモジュールの名前を確認するには、プロジェクトのリポジトリにある .gitmodules ファイルを開いてプレビューしてください。例えば、上流の開発者が lib-dependency という名前のリポジトリを、下流の libs/libdep という名前のサブモジュールとして .gitmodules に登録することができます。 

source=("git+https://example.org/main-project/main-project.git"
        "git+https://example.org/lib-dependency/lib-dependency.git")

prepare() {
  cd main-project
  git submodule init
  git config submodule.libs/libdep.url "$srcdir/lib-dependency"
  git -c protocol.file.allow=always submodule update
}
「https://wiki.archlinux.jp/index.php?title=VCS_パッケージガイドライン&oldid=34598」から取得