Guidelines

Properly suffix pkgname with -cvs, -svn, -hg, -darcs, -bzr, -git etc. If the package tracks a moving development trunk it should be given a suffix. If the package fetches a release from a VCS tag then it should not be given a suffix. Use this rule of thumb: if the output of the package depends on the time at which it was compiled, append a suffix; otherwise do not.

A VCS package may be updated as and when needed to adopt changes to the build system, including ammendments to dependencies, URL, sources, etc. If the revision number remains the same after such an update, but produces a resulting binary which is different, increasing the pkgrel is mandatory. If both the revision number and the resulting binary remain the same, pkgrel should be kept intact. There is no need to update the VCS package just to accommodate a revision bump, but one may choose to do so.

When makepkg is run, by default it will check for newer revisions and then update the pkgver in the PKGBUILD. Look at --holdver in man makepkg if you want otherwise. --holdver only works for cvs and svn, which allow checkout of older revisions.

Check for package conflicts. For example fluxbox-svn will conflict with fluxbox. In this case, you need to use conflicts=('fluxbox').

Use the provides field so that packages that require the non-VCS package can be installed (provides=('fluxbox')).

You should AVOID using replaces=... as it generally causes unnecessary problems.

When using/defining the cvsroot, use anonymous:@ rather than anonymous@ to avoid a password prompt and having to enter a blank password OR use anonymous:password@ if a password is required.

To preserve the integrity of the checked-out code consider copying the original build directory if you have to make edits. For example, having checked out source code to src/$_cvsmod from $startdir you can use:

mkdir src/$_cvsmod-build
cd src/$_cvsmod-build
../$_cvsmod/configure

or:

cp -r src/$_cvsmod src/$_cvsmod-build
cd src/$_cvsmod-build

If you are using pacman 4.1 (currently the development version) then this is no longer needed. Pacman works with vcs sources in a totally different way.

With the introduction of the AUR, it is most important to avoid using backtick execution to create package variables. makepkg will automatically bump the pkgver anyway when building the package (unless --holdver is used).

Starting with pacman 4.1, there vcs sources are handled more similarly to other sources. This removes the need for a -build directory. A quick explanation of what pacman does now using git as an example:

makepkg sees that the source is a vcs (in this case git) source in the source= array in two ways: either the url is a git:// url or the source is written as git+https://

Sources can be specified in a few ways: Either the url is obviously a vcs url (git://, etc.) or the url is preceded by the type of vcs used (git+https://)

I personally prefer the second, but it does not create sequential versions without tags in the git repository.

Tips

You should make sure that there are no VCS directories and files left over in your package. If there are, you may want to remove them, by adding a command similar to this one at the end of the the package() script:

rm -rf $(find "$pkgdir" -type d -name ".svn")

When using Git, one can speed up the cloning operation using the --depth=1 parameter. This creates a shallow clone, and has only the last change history - since histories are unimportant for builds most of the time.

# Contributor: Dave Reisner <d@falconindy.com>
# Edited for pacman 4.1 by William Giokas (KaiSforza) <1007380@gmail.com>
pkgname=expac-git
pkgver=
pkgrel=1
pkgdesc="pacman database extraction utility"
arch=('i686' 'x86_64')
url="http://github.com/falconindy/expac"
license=('MIT')
depends=('pacman')
makedepends=('git' 'perl')
conflicts=('expac')
provides=('expac')
# here is the fun bit. makepkg knows it's a git repo because the url starts with 'git'
# it then knows to checkout the branch 'pacman41' upon cloning, expediating versioning.
source=("git://github.com/falconindy/expac.git#branch=pacman41")
# because the sources are not static, skip checksums
md5sums=('SKIP')
_gitname="expac"
pkgver() {
cd "$srcdir/$_gitname"
echo $(git describe --always | sed 's/-/./g')
# for git, if the repo has no tags, comment out the above and uncommnet the next line:
#echo "$(git shortlog | grep -c '\s\+').$(git describe --always)"
# This will give you a count of the total commits and the hash of the commit you are on.
# Useful if you're making a repository with git packages so that they can have sequential
# version numbers. (Else a pacman -Syu may not update the package)
}
build() {
cd "$srcdir/$_gitname"
make
}
package() {
cd "$srcdir/$_gitname"
make PREFIX=/usr DESTDIR="$pkgdir" install
}

Temporary build directories: When using Git, and where you need to create a separate build directory (e.g., for building/compiling), you should avoid copying over the .git directory located in the parent folder because it contains history information that Git uses internally. With repos with thousands of commits, this .git directory will contain upwards of hundreds of MiB of useless commit history that has *nothing* to do with the current working tree. The only time you'd need to copy over the .git directory itself is when you need to build from a specific, older commit (which is generally never the case as the point of a VCS PKGBUILD is to pull from the latest bleeding edge commit). Thus, instead of