VCS package guidelines (简体中文)

From ArchWiki
Revision as of 08:07, 5 April 2013 by Fengchao (talk | contribs) (Sync with English version.)
Jump to: navigation, search

zh-TW:VCS PKGBUILD Guidelines Template:Package Guidelines


附注: please use the first argument of the template to provide more detailed indications.

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


The ABS package provides prototypes for cvs, svn, git, mercurial, and darcs PKGBUILDs. When abs is installed, you can find them in /usr/share/pacman. Latest versions can be found in the prototypes directory in the ABS Git repository.


  • 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.
  • Don't forget to include the appropriate VCS tool (cvs, subversion, git, ...) in makedepends.
  • 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:
mkdir "$srcdir/$_vcsname-build"

cd "$srcdir/$_vcsname-build"


cp -r "$srcdir/$_vcsname" "$srcdir/$_vcsname-build"
cd "$srcdir/$_vcsname-build"
  • 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:

  • 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.
  • vcs+ is needed for URLs that do not reflect the VCS type, like http://some_distant_repo
  • #fragment is an optional parameter which can be used to pull a specific branch or commit. The list of recognized fragments is documented in the PKGBUILD manpage
  • finally dir is used to change the default name of the local repo into something more relevant than trunk for example
Note: This is useful in case you want to keep several local repos lying around.

Here is an example of what a git source array could look like:


pkgver autobump

The pkgver autobump is now achieved via a dedicated pkgver() function. This allows for better control over the pkgver, following are examples for several VCS.


With tags:

pkgver () {
  cd "$srcdir"/local_repo
  git describe --always | sed 's|-|.|g'

Without tags:

pkgver () {
  cd "$srcdir"/local_repo
  echo "0.$(git rev-list --count HEAD).$(git describe --always)"


pkgver() {
  cd "$SRCDEST"/local_repo
Note: The copy inside $srcdir is made using svn export which does not create working copies, any svn related command has to be used in the local repo, hence $SRCDEST.


pkgver() {
  cd "$srcdir"/local_repo
  hg identify -ni | awk 'BEGIN{OFS=".";} {print $2,$1}'


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


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

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


  • 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:
find "$pkgdir" -type d -name ".svn" -exec rm -rf '{}' +;
  • 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.
git clone --depth 1 git://hostname.dom/project.git 
  • It's possible to create the package also from a branch other than the master. To do so add --branch branch_name after the first git clone, in this way:
git clone "$_gitroot" "$_gitname" --branch branch_name

Remember to save package with a different name, for example pkgname-branchname-git, in order to avoid confusion with the package from the branch master.

  • Copy paste script when building from repo

If you are lazy here is a sample script when making git-based PKGBUILDs. This is not needed if you are using pacman 4.1 or later.

 cd "$srcdir"
 msg "Connecting to GIT server..."
 if [[ -d "$_gitname" ]] ; then
   cd "$_gitname" && git pull origin
   msg "The local files are updated."
   git clone --depth 1 "$_gitroot" "$_gitname"
 msg "GIT checkout done or server timeout"
 # change dir and prepare to call configure, make etc
 cd "$srcdir/$_gitname"
  • Here is an example of a Git PKGBUILD in pacman 4.1:
# Contributor: Dave Reisner <> 
# Edited for pacman 4.1 by William Giokas (KaiSforza) <>

pkgdesc="pacman database extraction utility"
arch=('i686' 'x86_64')
makedepends=('git' 'perl')

# 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.
# because the sources are not static, skip checksums

pkgver() {
  cd "$srcdir/$_gitname"
  echo $(git describe --always | sed 's/-/./g')
  # for git, if the repo has no tags, comment out the above and uncomment the next line:
  #echo "0.$(git rev-list --count $branch).$(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"

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
rm -rf "$srcdir/$_gitname-build"
cp -R "$srcdir/$_gitname" "$srcdir/${_gitname}-build" # copy everything, including the useless .git directory
cd "$srcdir/${_gitname}-build"
make # build/compile from source

you should do

rm -rf "$srcdir/$_gitname-build"
git clone "$srcdir/$_gitname" "$srcdir/${_gitname}-build" # if on same partition, will just hard link all of the .git directory
cd "$srcdir/$_gitname-build"
make # build/compile from source

to cut down on build time and disk usage. As of pacman 4.1, this is obsolete.