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

提供: ArchWiki
2020年3月7日 (土) 18:29時点におけるHayao0819 (トーク | 投稿記録)による版 (→‎関数 pkgver())
ナビゲーションに移動 検索に移動

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

プロトタイプ

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

ガイドライン

  • pkgname の末尾に -cvs, -svn, -hg, -darcs, -bzr, -git などを付けて下さい。パッケージが特定のリリースを取得する場合は別です。
  • 依存関係, URL, ソースなどの変更を行なったことで作られるパッケージが異なるようになった時は pkgrel の値を増やして下さい。pkgver を変える必要はありません。
  • --holdver を使うことで makepkgpkgver を更新するのを止めることができます (参照: makepkg(8))
  • パッケージに conflicts と provides を含めて下さい (例えば fluxbox-gitAUR なら: conflicts=('fluxbox')provides=('fluxbox'))。
  • replaces=() は一般的に不必要な問題を起こすので使わないで下さい。
  • cvsroot を使う場合、空のパスワードや anonymous:password@ を入力するのを避けるために anonymous@ ではなく anonymous:@ を使って下さい。
  • makedepends=() に適当な VCS ツールを含めて下さい (cvs, subversion, git, ...)。
  • ソースが固定されないので、チェックサムは md5sums=()'SKIP' を追加してスキップしてください。

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')

関数 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 の 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 サブモジュールは少しトリッキーなことをする必要があります。サブモジュールの URL を直接 source に加えて、それから prepare() でそれらを使うようにしてください。以下のようになります:

source=("git://somewhere.org/something/something.git"
        "git://somewhere.org/mysubmodule/mysubmodule.git")

prepare() {
    cd something
    git submodule init
    git config submodule.mysubmodule.url $srcdir/mysubmodule
    git submodule update
}