「VCS パッケージガイドライン」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(校正(でき・出来))
 
(他の1人の利用者による、間の3版が非表示)
9行目: 9行目:
   
 
== プロトタイプ ==
 
== プロトタイプ ==
  +
{{Pkg|pacman}} パッケージに含まれている PKGBUILD のプロトタイプだけを使うようにしてください ({{ic|/usr/share/pacman}} の {{ic|PKGBUILD-split.proto}}, {{ic|PKGBUILD-vcs.proto}}, {{ic|PKGBUILD.proto}})。
 
  +
{{Pkg|pacman}} パッケージで提供されている PKGBUILD プロトタイプ ({{ic|/usr/share/pacman}} にある {{ic|PKGBUILD-split.proto}}, {{ic|PKGBUILD-vcs.proto}}, {{ic|PKGBUILD.proto}}) だけを使ってください。
   
 
== ガイドライン ==
 
== ガイドライン ==
56行目: 57行目:
 
=== 関数 pkgver() ===
 
=== 関数 pkgver() ===
   
{{ic|pkgver()}} 関数を使うことで {{ic|pkgver}} を自動で更新することが可能です。これによって {{ic|pkgver}} をより良くコントロールすることが出来るようになります。メンテナは {{ic|pkgver}} を意味あるものに扱うべきです。
+
{{ic|pkgver()}} 関数を使うことで {{ic|pkgver}} を自動で更新することが可能です。これによって {{ic|pkgver}} をより良くコントロールすることができるようになります。メンテナは {{ic|pkgver}} を意味あるものに扱うべきです。
   
 
次のバージョンフォーマットが推奨されています: ''RELEASE.rREVISION''。''REVISION'' はソースツリーの変更毎に増える番号です (VCS のリビジョンと同じ)。最新の VCS タグは ''RELEASE'' に使うことができます。公開リリースやリポジトリのタグがない場合、ゼロをリリース番号に使ったり ''RELEASE'' を完全に省いて ''rREVISION'' のようにバージョンを使って下さい。公開リリースが存在してリポジトリにタグがないときは開発者はプロジェクトファイルのパースなどによってリリースバージョンを取得します。
 
次のバージョンフォーマットが推奨されています: ''RELEASE.rREVISION''。''REVISION'' はソースツリーの変更毎に増える番号です (VCS のリビジョンと同じ)。最新の VCS タグは ''RELEASE'' に使うことができます。公開リリースやリポジトリのタグがない場合、ゼロをリリース番号に使ったり ''RELEASE'' を完全に省いて ''rREVISION'' のようにバージョンを使って下さい。公開リリースが存在してリポジトリにタグがないときは開発者はプロジェクトファイルのパースなどによってリリースバージョンを取得します。
160行目: 161行目:
 
}}
 
}}
   
ソースツリーの状態を一意に示しているのではないので、出来る限り使わないで下さい。
+
ソースツリーの状態を一意に示しているのではないので、できるる限り使わないで下さい。
   
 
== ヒントとテクニック ==
 
== ヒントとテクニック ==
166行目: 167行目:
 
=== Git サブモジュール ===
 
=== Git サブモジュール ===
   
Git サブモジュールは少しトリッキーなことをする必要があります。サブモジュールの URL を直接 source に加えてそれから prepare() でそれらを使ようにしてください。以下ようになりま:
+
Git サブモジュールは、注意が必要す。サブモジュール自身の URL を直接 sources 配列{{ic|prepare()}} の中でそれらを参照するとい
   
ダウンストリームプロジェクト開発者は、サブモジュールにアップストリームモジュールのリポジトリと同じ名前を付けることはできません。git サブモジュールの名前を表示するには、プロジェクトのリポジトリ内の {{ic|.gitmodules}} ファイルに移動してプレビューしますたとえば、上流の開発者によって {{ic|''lib-dependency''}} という名前のリポジトリ{{ic|.gitmodules に {{ic|''libs/libdep''}} という名前のサブモジュールとして登録され場合あります。}}
+
下流プロジェクト開発者は、上流モジュールのリポジトリと同じ名前のサブモジュール作成することはできません。git サブモジュールの名前を確認するには、プロジェクトのリポジトリにある {{ic|.gitmodules}} ファイルを開いてプレビューしてくださいえば、上流の開発者 {{ic|''lib-dependency''}} という名前のリポジトリ下流の {{ic|''libs/libdep''}} という名前のサブモジュールとして {{ic|.gitmodules}} に登録ことできます。
   
 
{{bc|<nowiki>
 
{{bc|<nowiki>

2024年7月10日 (水) 19:56時点における最新版

バージョン管理システムは通常の安定版のパッケージと最新の (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 を使うことで makepkgpkgver を更新するのを止めることができます (参照: makepkg(8))

競合と依存関係

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

認証とセキュリティ

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

VCS ソース

ノート: Pacman 4.1 は以下の VCS ソースをサポートしています: bzr, git, hg, svn。サポートされている VCS の一覧は man PKGBUILDfragment セクションや 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.rREVISIONREVISION はソースツリーの変更毎に増える番号です (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
}