User:Quequotion/VCS package guidelines

Version control systems can be used for retrieval of source code for both usual statically versioned packages and latest (trunk) version of a development branch. This article covers both cases.

Prototypes

Use only the PKGBUILD prototypes provided in the pacman package (PKGBUILD-split.proto, PKGBUILD-vcs.proto and PKGBUILD.proto in /usr/share/pacman).

Guidelines

Package naming

Suffix pkgbase with -cvs, -svn, -hg, -darcs, -bzr, -git etc. unless the package fetches a specific release.

Versioning

If the resulting package is different after making any changes, increasing the pkgrel is mandatory. Changing the pkgver is not.

Tip: --holdver can be used to prevent makepkg from updating the pkgver (see: makepkg(8))

Conflicts and dependencies

• Include the standard version of the package in conflicts and provides (e.g. for fluxbox-git^AUR: conflicts=('fluxbox') and provides=('fluxbox')).

• replaces should be used only when a package deprecates another. (ie, the pkgbase has changed and the previous version has been deleted)

• Include the appropriate VCS tool in makedepends (cvs, subversion, git, ...).

Authentication and security

• When using the cvsroot, use anonymous:@ rather than anonymous@ to avoid having to enter a blank password or anonymous:password@, if one is required.

• Because the sources are not static, skip the checksum in *sums() with the value 'SKIP'.

VCS sources

Note: Pacman 4.1 supports the following VCS sources: bzr, git, hg and svn. See the fragment section of PKGBUILD(5) § USING VCS SOURCES for a list of supported VCS.

Starting with pacman 4.1, the VCS sources should be specified in the source=() array and will be treated like any other source. makepkg will clone/checkout/branch the repository into $SRCDEST (same as $startdir if not set in makepkg.conf(5)) and copy it to $srcdir (in a specific way to each VCS). The local repository is left untouched, thus invalidating the need for a -build directory.

The general format of a VCS source=() array is:

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

• folder (optional) is used to change the default repository name to something more relevant (e.g. than trunk) or to preserve the previous sources.
• vcs+ is needed for URLs that do not reflect the VCS type, e.g. git+http://some_repo.
• url is the URL to the distant or local repository.
• #fragment (optional) is needed to pull a specific branch or commit. See PKGBUILD(5) for more information on the fragments available for each VCS.

An example Git source array:

source=('project_name::git+https://project_url#branch=project_branch')

The pkgver() function

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. To use pkgver(), you still need to declare the pkgver variable with the most recent value. makepkg will invoke function pkgver(), and update variable pkgver accordingly.

It is recommended to have following version format: RELEASE.rREVISION where REVISION is a monotonically increasing number that uniquely identifies the source tree (VCS revisions do this). If there are no public releases and no repository tags then zero could be used as a release number or you can drop RELEASE completely and use version number that looks like rREVISION. If there are public releases but repo has no tags then the developer should get the release version somehow e.g. by parsing the project files.

The revision number delimiter ("r" right before REVISION) is important. This delimiter allows to avoid problems in case if upstream decides to make its first release or uses versions with different number of components. E.g. if at revision "455" upstream decides to release version 0.1 then the revision delimiter preserves version monotonicity - 0.1.r456 > r454. Without the delimiter monotonicity fails - 0.1.456 < 454.

See PKGBUILD-vcs.proto for generic examples showing the intended output.

Git

Using the most recent annotated tag reachable from the last commit:

pkgver() {
  cd "$pkgname"
  git describe --long | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}

2.0.r6.ga17a017

Using the most recent un-annotated tag reachable from the last commit:

pkgver() {
  cd "$pkgname"
  git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}

0.71.r115.gd95ee07

In case if the git tag does not contain dashes then one can use simpler sed expression sed 's/-/.r/;s/-/./'.

If tag contains a prefix, like v or project name then it should be cut off:

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

If there are no tags then use number of revisions since beginning of the history:

pkgver() {
  cd "$pkgname"
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

r1142.a17a017

Version and only commit/revision number (SHA1 omitted; however, without a SHA1 quick referencing of an exact revision is lost if not mindful of versioning):

git describe --long | sed -r 's/-([0-9,a-g,A-G]{7}.*)//' | sed 's/-/./g'

Both methods can also be combined, to support repositories that start without a tag but get tagged later on (uses a 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

Note: If the project has releases you should use them instead of the 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

In case no satisfactory pkgver can be extracted from the repository, the current date can be used:

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

20130408

Although it does not identify source tree state uniquely, so avoid it if possible.

Tips and tricks

Git submodules

Git submodules are a little tricky to do. The idea is to add the URLs of the submodules themselves directly to the sources array and then reference them during prepare(). This could look like this:

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
}