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 $srcdir/$_vcsname from a host you can use:

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

Pacman 4.1

VCS sources

Starting with pacman 4.1, the VCS sources are handled differently. They can be specified in the source array and will be treated like any other source: makepkg will clone/checkout/branch the distant repo in a subdirectory inside the $SRCDEST directory defined in /etc/makepkg.conf. The directory is then copied (in a way that is specific to each VCS) in $srcdir, as a result the local repo is left untouched and there is no need for a -build directory anymore. Any subsequent attempt at building a package will only do incremental updates to the local repo, provided it was not erased.

The general format of a VCS source array is as follows:

source=('[dir::][vcs+]url[#fragment]')

url is pretty self-explanatory, this is the URL to the distant repo

Note: The URL can also point to a local repo instead of a distant one if so desired.

Bazaar limitation

Using any other http://, https:// or ssh:// URL will prevent makepkg from being able to update the local repo. Additionnally, using lp:project_name will not work at all.

The correct url can be obtained by running:

$ bzr config parent_location

or:

$ bzr info | grep parent | sed 's| parent branch: ||'

inside the local repo.

pkgver autobump

The pkgver autobump is now achieved via a dedicated pkgver() function. This allows for better control over the pkgver, and maintainers should favor a pkgver that makes sense. Following are some examples for several VCS.

Mercurial

Bazaar

pkgver() {
cd "$srcdir"/local_repo
bzr revno
}

Fallback

The following can be used in case no satisfactory pkgver can be extracted from the repo.

pkgver() {
date +"%Y%m%d"
}

Tips

Removing SVN leftovers

You should make sure that there are no SVN 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() function: