VCS 軟件打包準則
32 位 – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – Web – Wine
不論是靜態版本的軟件包,還是開發分支最新(主幹)版本的軟件包,都可以用版本控制系統檢索原始碼。本文涵蓋了這兩種情況。
原型[編輯 | 編輯原始碼]
只使用 pacman包 提供的 PKGBUILD 原型文件(位於 /usr/share/pacman
的 PKGBUILD-split.proto
、PKGBUILD-vcs.proto
和 PKGBUILD.proto
)。
準則[編輯 | 編輯原始碼]
軟件包命名[編輯 | 編輯原始碼]
- 使用
pkgname
加上後綴-cvs
、-svn
、-hg
、-darcs
、-bzr
、-git
等(除非該軟件包指定了特定的版本)。
版本管理[編輯 | 編輯原始碼]
- 如果在更改了依賴關係、URL 或原始碼等參數之後,生成的軟件包有所不同,請將
pkgver
更新為最新版本。如果pkgver
在上次更新PKGBUILD
後不變,則需增加pkgrel
。
。
衝突和依賴[編輯 | 編輯原始碼]
- Include what the package conflicts with and provides (e.g. for fluxbox-gitAUR:
conflicts=('fluxbox')
andprovides=('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 thananonymous@
to avoid having to enter a blank password oranonymous:password@
, if one is required. - Because the sources are not static, skip the checksum in
md5sums=()
by adding'SKIP'
.
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. thantrunk
) 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:
source=('project_name::git+https://project_url#branch=project_branch')
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' }
2.0.r6.ga17a017
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' }
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 --abbrev=7 | 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=7 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 --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:]]}" }
r8546
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
備用方法[編輯 | 編輯原始碼]
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.
提示與技巧[編輯 | 編輯原始碼]
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.
source=("git+https://example.org/main-project/main-project.git" "git+https://example.org/lib-dependency/lib-dependency.git") prepare() { cd main-project git submodule init git config submodule.libs/libdep.url "$srcdir/lib-dependency" git -c protocol.file.allow=always submodule update }