VCS 软件打包准则

来自 Arch Linux 中文维基
Arch 打包准则

32 位CLRCMakeCrossDKMSEclipseElectronFontFree PascalGNOMEGoHaskellJavaKDEKernelLispMesonMinGWNode.jsNonfreeOCamlPerlPHPPythonRRubyRustVCSWebWine


原型[编辑 | 编辑源代码]

只使用 pacman 提供的 PKGBUILD 原型文件(位于 /usr/share/pacmanPKGBUILD-split.protoPKGBUILD-vcs.protoPKGBUILD.proto)。

准则[编辑 | 编辑源代码]

软件包命名[编辑 | 编辑源代码]

  • 使用 pkgname 加上后缀 -cvs-svn-hg-darcs-bzr-git 等(除非该软件包指定了特定的版本)。

版本管理[编辑 | 编辑源代码]

  • 如果在更改了依赖关系、URL 或源代码等参数之后,生成的软件包有所不同,请将 pkgver 更新为最新版本。如果 pkgver 在上次更新PKGBUILD 后不变,则需增加 pkgrel
提示:可使用 --holdver 来防止 makepkg 更新 pkgver。(参见:makepkg(8))

冲突和依赖[编辑 | 编辑源代码]

  • Include what the package conflicts with and provides (e.g. for fluxbox-gitAUR: conflicts=('fluxbox') and provides=('fluxbox')).
  • replaces=() generally causes unnecessary problems and should be avoided.
  • Include the appropriate VCS tool in makedepends=() (cvs, subversion, git, ...).

身份认证和安全[编辑 | 编辑源代码]

  • 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 md5sums=() by adding 'SKIP'.

VCS 源[编辑 | 编辑源代码]

注意: Using sparse or shallow clones is voluntarily not supported (see FS#34677 and the mailing list).

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:

  • 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) § USING VCS SOURCES for a list of supported VCS and the respective fragments available.

An example Git source array:

警告: Make sure not to use the pkgver variable in the folder field, as the variable may be changed during the pkgver() function call, which will make it impossible to access the created folder in subsequent functions.

pkgver() 函数[编辑 | 编辑源代码]

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

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

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

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

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=7 HEAD)"

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 --abbrev=7 --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):

pkgver() {
  cd "$pkgname"
  ( set -o pipefail
    git describe --long --abbrev=7 2>/dev/null | sed 's/\([^-]*-g\)/r\1/;s/-/./g' ||
    printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short=7 HEAD)"
0.9.9.r27.g2b039da  # if tags exist
r1581.2b039da       # else fallback

子版本[编辑 | 编辑源代码]

pkgver() {
  cd "$pkgname"
  local ver="$(svnversion)"
  printf "r%s" "${ver//[[:alpha:]]}"
注意: 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)"

Bazaar[编辑 | 编辑源代码]

pkgver() {
  cd "$pkgname"
  printf "r%s" "$(bzr revno)"

备用方法[编辑 | 编辑源代码]

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

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

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

提示与技巧[编辑 | 编辑源代码]

Git 子模块[编辑 | 编辑源代码]

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

Downstream project developers may not name their submodule as the same name as the upstream module's repository. To view the name of the git submodules, go to the .gitmodules file in the project's repository and preview it. For example, a repository named lib-dependency by the upstream developers may be registered as a submodule named libs/libdep in .gitmodules downstream.


prepare() {
  cd main-project
  git submodule init
  git config submodule.libs/libdep.url "$srcdir/lib-dependency"
  git -c protocol.file.allow=always submodule update