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

提供: ArchWiki
ナビゲーションに移動 検索に移動
細
(校正（でき・出来）)
 
(4人の利用者による、間の15版が非表示)
1行目: 1行目:
 
[[Category:パッケージ開発]]
  
[[Category:パッケージ開発]]
−
[[en:VCS PKGBUILD Guidelines]]
 +
[[en:VCS package guidelines]]
−
[[it:VCS PKGBUILD Guidelines]]
 +
[[it:VCS package guidelines]]
−
[[zh-CN:VCS PKGBUILD Guidelines]]
 +
[[zh-hans:VCS package guidelines]]
−
[[zh-TW:VCS PKGBUILD Guidelines]]
 +
[[zh-hant:VCS package guidelines]]
 
{{Package Guidelines}}
  
{{Package Guidelines}}
   
9行目: 9行目:
   
 
== プロトタイプ ==
  
== プロトタイプ ==
−
{{Warning|The prototype files provided in the {{Pkg|abs}} package and in [https://projects.archlinux.org/abs.git/tree/prototypes the ABS Git repository] are ''significantly'' out-of-date. Do ''not'' consider the prototypes to be authoritative in any way. See {{Bug|34485}}.}}
  
   
  +
{{Pkg|pacman}} パッケージで提供されている PKGBUILD プロトタイプ ({{ic|/usr/share/pacman}} にある {{ic|PKGBUILD-split.proto}}, {{ic|PKGBUILD-vcs.proto}}, {{ic|PKGBUILD.proto}}) だけを使ってください。
−
[[Arch Build System|Arch Build System]] の {{Pkg|abs}} パッケージは [[CVS]], [[SVN]], [[Git]], [[Mercurial]], [[Wikipedia:Darcs|Darcs]] の [[PKGBUILD]] のプロトタイプを提供しています。{{Pkg|abs}} をインストールしたら、{{ic|/usr/share/pacman}} にプロトタイプが入っています。最新のバージョンは [https://projects.archlinux.org/abs.git/tree/prototypes ABS Git リポジトリの prototypes ディレクトリ]にあります。
  
   
 
== ガイドライン ==
  
== ガイドライン ==
   
  +
=== パッケージの命名 ===
−
* {{Ic|pkgname}} の末尾に {{Ic|-cvs}}, {{Ic|-svn}}, {{Ic|-hg}}, {{Ic|-darcs}}, {{Ic|-bzr}}, {{Ic|-git}} などを付けて下さい。パッケージが特定のリリースを取得する場合は別です。
  
  +
  +
{{Ic|pkgname}} の末尾に {{Ic|-cvs}}, {{Ic|-svn}}, {{Ic|-hg}}, {{Ic|-darcs}}, {{Ic|-bzr}}, {{Ic|-git}} などを付けて下さい。パッケージが特定のリリースを取得する場合は別です。
  +
  +
=== バージョン管理 ===
   
 
* 依存関係, URL, ソースなどの変更を行なったことで作られるパッケージが異なるようになった時は {{Ic|pkgrel}} の値を増やして下さい。{{ic|pkgver}} を変える必要はありません。
  
* 依存関係, URL, ソースなどの変更を行なったことで作られるパッケージが異なるようになった時は {{Ic|pkgrel}} の値を増やして下さい。{{ic|pkgver}} を変える必要はありません。
  +
{{Tip|{{ic|--holdver}} を使用すると、[[makepkg]] による {{ic|pkgver}} の更新を防ぐことができます ({{man|8|makepkg}} を参照)}}
   
 
* {{Ic|--holdver}} を使うことで [[makepkg|makepkg]] が {{ic|pkgver}} を更新するのを止めることができます (参照: [https://www.archlinux.org/pacman/makepkg.8.html makepkg(8)])
  
* {{Ic|--holdver}} を使うことで [[makepkg|makepkg]] が {{ic|pkgver}} を更新するのを止めることができます (参照: [https://www.archlinux.org/pacman/makepkg.8.html makepkg(8)])
   
  +
=== 競合と依存関係 ===
−
* パッケージに conflicts と provides を含めて下さい (例えば {{AUR|fluxbox-git}} なら: {{Ic|1=conflicts=('fluxbox')}} と {{Ic|1=provides=('fluxbox')}})。
  
   
  +
* * パッケージが競合するものと提供するものを含めます (例: {{AUR|fluxbox-git}}: {{ic|1=conflicts=('fluxbox')}} および {{ic|1=provides=('fluxbox'))}}
−
* {{Ic|1=replaces=()}} は一般的に不必要な問題を起こすので使わないで下さい。
  
  +
* {{ic|1=replaces=()}} は通常、不要な問題を引き起こすため、回避する必要があります。
  +
* 適切な VCS ツールを {{ic|1=makedepends=()}} ({{pkg|cvs}}、{{pkg|subversion}}、{{pkg|git}}、...) に含めます。
   
  +
=== 認証とセキュリティ ===
−
* cvsroot を使う場合、空のパスワードや {{Ic|anonymous:password@}} を入力するのを避けるために {{Ic|anonymous@}} ではなく {{Ic|anonymous:@}} を使って下さい。
  
   
  +
* cvsroot を使用する場合は、空のパスワードまたは {{ic|anonymous:password@}} (必要な場合) を入力する手間を避けるために、{{ic|anonymous@}} ではなく {{ic|anonymous:@}} を使用してください。
−
* {{Ic|1=makedepends=()}} に適当な VCS ツールを含めて下さい ({{pkg|cvs}}, {{pkg|subversion}}, {{pkg|git}}, ...)。
  
  +
* ソースは静的ではないため、{{ic|'SKIP'}} を追加して、{{ic|1=sha256sums=()}} のチェックサムをスキップします。
   
 
=== VCS ソース ===
  
=== VCS ソース ===
  +
 
{{Note|Pacman 4.1 は以下の VCS ソースをサポートしています: {{ic|bzr}}, {{ic|git}}, {{ic|hg}}, {{ic|svn}}。サポートされている VCS の一覧は {{ic|man PKGBUILD}} の {{ic|fragment}} セクションや [https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5)] を見て下さい。}}
  
{{Note|Pacman 4.1 は以下の VCS ソースをサポートしています: {{ic|bzr}}, {{ic|git}}, {{ic|hg}}, {{ic|svn}}。サポートされている VCS の一覧は {{ic|man PKGBUILD}} の {{ic|fragment}} セクションや [https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5)] を見て下さい。}}
   
43行目: 51行目:
   
 
Git の source の例:
  
Git の source の例:
−
source=('project_name::git+http://project_url#branch=project_branch')
 +
<nowiki>source=('project_name::git+http://project_url#branch=project_branch')</nowiki>
  +
  +
{{Warning|{{ic|folder}} フィールドでは {{ic|pkgver}} 変数を使用しないようにしてください。変数は {{ic|pkgver()}} 関数呼び出し中に変更される可能性があり、使用できなくなります。後続の機能で作成されたフォルダーにアクセスします。}}
   
 
=== 関数 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'' のようにバージョンを使って下さい。公開リリースが存在してリポジトリにタグがないときは開発者はプロジェクトファイルのパースなどによってリリースバージョンを取得します。
  +
  +
リビジョン番号の区分け (REVISION の前の "r") は重要です。開発元が初めてリリースを行うことを決めたり、別のバージョン方式によるバージョンを付けるようになった場合に問題を避けることができます。例えばリビジョン "455" で、上流がバージョン 0.1 をリリースした場合、リビジョンの区分けをしていれば問題なくバージョンアップが認識されます ({{ic|0.1.r456 > r454}})。区分けがないとバージョンアップと認識されません ({{ic|0.1.456 < 454}})。
   
 
以下は''意図した''出力を行うサンプルです:
  
以下は''意図した''出力を行うサンプルです:
57行目: 70行目:
   
 
{{hc|<nowiki>pkgver() {
  
{{hc|<nowiki>pkgver() {
−
cd "$srcdir/repo"
 +
cd "$pkgname"
−
git describe --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g'
 +
git describe --long | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
 
}</nowiki>|
  
}</nowiki>|
 
2.0.r6.ga17a017
  
2.0.r6.ga17a017
66行目: 79行目:
   
 
{{hc|<nowiki>pkgver() {
  
{{hc|<nowiki>pkgver() {
−
cd "$srcdir/repo"
 +
cd "$pkgname"
−
git describe --long --tags | sed -E 's/([^-]*-g)/r\1/;s/-/./g'
 +
git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
 
}</nowiki>|
  
}</nowiki>|
 
0.71.r115.gd95ee07
  
0.71.r115.gd95ee07
  +
}}
  +
  +
git タグにダッシュが含まれていない場合、sed はもっとシンプルにできます: {{ic|sed 's/-/.r/;s/-/./'}}。
  +
  +
タグに {{ic|v}} やプロジェクト名などが付いている場合、取り除きます:
  +
  +
{{hc|<nowiki>
  +
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'
  +
}</nowiki>|
  +
6.1.r3.gd77e105
 
}}
  
}}
   
75行目: 101行目:
   
 
{{hc|<nowiki>pkgver() {
  
{{hc|<nowiki>pkgver() {
−
cd "$srcdir/repo"
 +
cd "$pkgname"
 
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
  
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
 
}</nowiki>|
  
}</nowiki>|
81行目: 107行目:
 
}}
  
}}
   
  +
バージョンとコミット/リビジョン番号のみ (SHA1 は省かれます。ただし、バージョンを忘れると実際のリビジョンがわからなくなります):
−
{{Note|SHA1 (この場合 {{ic|a17a017}}) はバージョンの比較には使われないため省略することができますが、使っているリビジョンの確認が簡単にできるのでデバッグに役立ちます。}}
  
  +
  +
git describe --long | sed -r 's/-([0-9,a-g,A-G]{7}.*)//' | sed 's/-/./'
  +
  +
両方を組み合わせて、タグが最初に付かないリポジトリに対応することもできます (bashism を使用):
  +
  +
{{hc|<nowiki>
  +
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)"
  +
)
  +
}</nowiki>|
  +
0.9.9.r27.g2b039da # if tags exist
  +
r1581.2b039da # else fallback
  +
}}
   
 
==== Subversion ====
  
==== Subversion ====
 
{{hc|<nowiki>pkgver() {
  
{{hc|<nowiki>pkgver() {
−
cd "$srcdir/repo"
 +
cd "$pkgname"
 
local ver="$(svnversion)"
  
local ver="$(svnversion)"
 
printf "r%s" "${ver//[[:alpha:]]}"
  
printf "r%s" "${ver//[[:alpha:]]}"
96行目: 138行目:
 
==== Mercurial ====
  
==== Mercurial ====
 
{{hc|<nowiki>pkgver() {
  
{{hc|<nowiki>pkgver() {
−
cd "$srcdir/repo"
 +
cd "$pkgname"
 
printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)"
  
printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)"
 
}</nowiki>|
  
}</nowiki>|
104行目: 146行目:
 
==== Bazaar ====
  
==== Bazaar ====
 
{{hc|<nowiki>pkgver() {
  
{{hc|<nowiki>pkgver() {
−
cd "$srcdir/repo"
 +
cd "$pkgname"
 
printf "r%s" "$(bzr revno)"
  
printf "r%s" "$(bzr revno)"
 
}</nowiki>|
  
}</nowiki>|
119行目: 161行目:
 
}}
  
}}
   
−
ソースツリーの状態を一意に示しているのではないので、出来る限り使わないで下さい。
 +
ソースツリーの状態を一意に示しているのではないので、できるる限り使わないで下さい。
   
  +
== ヒントとテクニック ==
−
== Tips ==
  
−  
−
=== Git の PKGBUILD のサンプル ===
  
−
# Maintainer: Dave Reisner <d@falconindy.com>
 
−
# Contributor: William Giokas (KaiSforza) <1007380@gmail.com>
  
−
 
−
pkgname=expac-git
  
−
pkgver=0.0.0
  
−
pkgrel=1
  
−
pkgdesc="Pacman database extraction utility"
  
−
arch=('i686' 'x86_64')
  
−
url="https://github.com/falconindy/expac"
  
−
license=('MIT')
  
−
depends=('pacman')
  
−
makedepends=('git')
  
−
conflicts=('expac')
  
−
provides=('expac')
  
−
# The git repo is detected by the 'git:' or 'git+' beginning. The branch
  
−
# '$pkgname' is then checked out upon cloning, expediating versioning:
  
−
#source=('git+https://github.com/falconindy/expac.git'
  
−
source=("$pkgname"::'git://github.com/falconindy/expac.git'
  
−
'expac_icon.png')
  
−
# Because the sources are not static, skip Git checksum:
  
−
md5sums=('SKIP'
  
−
'020c36e38466b68cbc7b3f93e2044b49')
  
−
 
−
pkgver() {
  
−
cd "$srcdir/$pkgname"
  
−
# Use the tag of the last commit
  
−
git describe --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g'
  
−
}
  
−
 
−
build() {
  
−
cd "$srcdir/$pkgname"
  
−
make
  
−
}
  
−
 
−
package() {
  
−
cd "$srcdir/$pkgname"
  
−
make PREFIX=/usr DESTDIR="$pkgdir" install
  
−
install -Dm644 "$srcdir/expac_icon.png" "$pkgdir/usr/share/pixmaps/expac.png"
  
−
}
  
   
 
=== Git サブモジュール ===
  
=== Git サブモジュール ===
−
Git サブモジュールは少しトリッキーなことをする必要があります。サブモジュールの URL を直接 source に加えて、それから prepare() でそれらを使うようにしてください。以下のようになります:
  
   
  +
Git のサブモジュールは、注意が必要です。サブモジュール自身の URL を直接 sources 配列に追加し、{{ic|prepare()}} の中でそれらを参照するというものです
−
source=("git://somewhere.org/something/something.git"
  
  +
−
"git://somewhere.org/mysubmodule/mysubmodule.git")
  
  +
下流プロジェクトの開発者は、上流モジュールのリポジトリと同じ名前のサブモジュールを作成することはできません。git サブモジュールの名前を確認するには、プロジェクトのリポジトリにある {{ic|.gitmodules}} ファイルを開いてプレビューしてください。例えば、上流の開発者が {{ic|''lib-dependency''}} という名前のリポジトリを、下流の {{ic|''libs/libdep''}} という名前のサブモジュールとして {{ic|.gitmodules}} に登録することができます。
−
 
  +
−
prepare() {
  
  +
{{bc|<nowiki>
−
cd something
  
  +
source=("git+https://example.org/main-project/main-project.git"
−
git submodule init
  
  +
"git+https://example.org/lib-dependency/lib-dependency.git")
−
git config submodule.mysubmodule.url $srcdir/mysubmodule
  
  +
−
git submodule update
  
  +
prepare() {
−
}
  
  +
cd main-project
  +
git submodule init
  +
git config submodule.libs/libdep.url "$srcdir/lib-dependency"
  +
git -c protocol.file.allow=always submodule update
  +
}
  +
</nowiki>}}

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

パッケージ作成ガイドライン

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=37940」から取得