[pacman-dev] [PATCH] Add PKGBUILD-vcs.proto

Allan McRae allan at archlinux.org
Tue Jan 28 06:30:04 EST 2014


On 26/01/14 03:38, Maxime Gauduin wrote:
> Add a proto for bzr, git, hg and svn PKGBUILDs and remove the
> corresponding protos from abs.
> 

Commit message needs updated.

> Signed-off-by: Maxime Gauduin <alucryd at gmail.com>
> ---
>  proto/PKGBUILD-vcs.proto | 95 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 95 insertions(+)
>  create mode 100644 proto/PKGBUILD-vcs.proto
> 
> diff --git a/proto/PKGBUILD-vcs.proto b/proto/PKGBUILD-vcs.proto
> new file mode 100644
> index 0000000..3aa7890
> --- /dev/null
> +++ b/proto/PKGBUILD-vcs.proto
> @@ -0,0 +1,95 @@
> +# This is an example PKGBUILD file. Use this as a start to creating your own,
> +# and remove these comments. For more information, see 'man PKGBUILD'.
> +# NOTE: Please fill out the license field for your package! If it is unknown,
> +# then please put 'unknown'.
> +
> +# The following guidelines are specific to BZR, GIT, HG and SVN packages.
> +# CVS and DARCS are not natively supported in pacman yet, please refer to the
> +# dedicated prototypes instead.
> +
> +# Maintainer: Your Name <youremail at domain.com>
> +pkgname=NAME-VCS # '-bzr', '-git', '-hg' or '-svn'
> +pkgver=VERSION
> +pkgrel=1

epoch=

> +pkgdesc=""
> +arch=()
> +url=""
> +license=('GPL')
> +groups=()
> +depends=()
> +makedepends=('VCS_PACKAGE') # 'bzr', 'git', 'mercurial' or 'subversion'

checkdepends=()
optdepends=()

> +provides=("${pkgname%-VCS}")
> +conflicts=("${pkgname%-VCS}")
> +replaces=()
> +backup=()
> +options=()
> +install=

changelog=

> +source=('DIR_NAME::VCS+REPO_URL#FRAGMENT')
> +noextract=()
> +md5sums=('SKIP')
> +
> +################################################################################
> +

Can we just refer to the "Using VCS Sources" in the PKGBUILD man page here?

> +# DIR_NAME: Use to change the source directory name if needed
> +
> +# VCS: Use to specify the VCS type, not needed when REPO_URL is explicit (for
> +# example git://URL, svn://URL or lp:REPO_NAME)
> +
> +# FRAGMENT: Use to pull a specific branch, commit/revision or tag
> +# Bazaar accepts the 'revision' keyword
> +# Git accepts the 'branch', 'commit' and 'tag' keywords
> +# Mercurial accepts the 'branch', 'revision' and 'tag' keywords
> +# Subversion accepts the 'revision' keyword
> +
> +# Examples:
> +# source=("lp:${pkgname%-bzr}#revision=42")
> +# source=("git+https://github.com/author/${pkgname%-git}.git#branch=unstable")
> +# source=('hg+https://bitbucket.org/author/project#tag=2.0')
> +# source=("${pkgname%-svn}::svn://svn.code.sf.net/p/project/code/trunk"}
> +
> +################################################################################
> +
> +pkgver() {
> +	cd "$srcdir/${pkgname%-VCS}"
> +
> +# The examples below are not absolute and need to be adapted to each repo. The
> +# general idea is to have VERSION='VER_NUM.rREV_NUM.HASH' or any subset in case
> +# VER_NUM or HASH are not available.


Why are we using "r" everywhere?  What is its advantage - especially in
the non-git cases?

And why adding "." between the segments instead of an underscore?   I
have seen a lot of software release version A.B followed by A.B.C, so
separating with a "." will break.


> +# Bazaar
> +	printf "r%s" "$(bzr revno)"
> +
> +# Git, tags available
> +	printf "%s" "$(git describe --long | sed 's/\([^-]*-\)g/r\1/;s/-/./g')"
> +
> +# Git, no tags available
> +	printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
> +
> +# Mercurial
> +	printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)"
> +
> +# Subversion
> +	printf "r%s" "$(svnversion | tr -d 'A-z')"
> +}
> +
> +prepare() {
> +	cd "$srcdir/${pkgname%-VCS}"
> +	patch -p1 -i "$srcdir/${pkgname%-VCS}.patch"
> +}
> +
> +build() {
> +	cd "$srcdir/${pkgname%-VCS}"
> +	./autogen.sh
> +	./configure --prefix=/usr
> +	make
> +}
> +
> +check() {
> +	cd "$srcdir/${pkgname%-VCS}"
> +	make -k check
> +}
> +
> +package() {
> +	cd "$srcdir/${pkgname%-VCS}"
> +	make DESTDIR="$pkgdir/" install
> +}
> 



More information about the pacman-dev mailing list