VCS package guidelines

• Suffix pkgname with -cvs, -svn, , -darcs, , etc. unless the package fetches a specific release.

• If the resulting package is different after changing e.g. the dependencies, URL or sources, update to the latest version. If has not changed since the last update to the , increase pkgrel instead.

• Include what the package conflicts with and provides (e.g. for fluxbox-git^AUR: and ).
• generally causes unnecessary problems and should be avoided.
• Include the appropriate VCS tool in (, , , ...).

• When using the cvsroot, use anonymous:@ rather than anonymous@ to avoid having to enter a blank password or , if one is required.
• Because the sources are not static, skip the checksum in by adding .

Starting with pacman 4.1, the VCS sources should be specified in the array and will be treated like any other source. will clone/checkout/branch the repository into (same as if not set in ) 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 array is:

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

• (optional) is used to change the default repository name to something more relevant (e.g. than ) or to preserve the previous sources.
• is needed for URLs that do not reflect the VCS type, e.g. .
• is the URL to the distant or local repository.
• (optional) is needed to pull a specific branch or commit. See for a list of supported VCS and the respective fragments available.

An example Git source array:

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

The autobump is now achieved via a dedicated pkgver() function. This allows for better control over the , and maintainers should favor a that makes sense. To use pkgver(), you still need to declare the variable with the most recent value. makepkg will invoke function pkgver(), and update variable 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 repository 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 - . Without the delimiter monotonicity fails - .

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

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

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

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 or project name then it should be cut off:

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

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 --tags | sed 's/\([^-]*\)-g.*/r\1/;s/-/./g'

Both methods can also be combined, to support repositories that start without a tag but get tagged later on (uses a bashism):

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

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

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

Project developers may not name their submodule as the same name as the module's repository. To view the name of the git submodules, go to the file in the project's repository and preview it. may be entered as externals/vendor/mysubmodule in .