VCS 软件包指南

出自 ArchWiki
(重定向自 VCS PKGBUILD 指南)
Arch 软件包指南

32 位 – CLR – CMake – 交叉编译 – DKMS – Eclipse 插件 – Electron – 字体 – Free Pascal – GNOME – Go – Haskell – Java – KDE – 内核模块 – Lisp – Meson – MinGW – Node.js – 非自由软件 – OCaml – Perl – PHP – Python – R – Ruby – Rust - 安全 – Shell – VCS – Web 应用 – Wine

相关文章

版本控制系统 可用于检索常用静态版本软件包的源代码，以及开发分支的最新（主干）版本。

提示： 使用 pacman 软件包提供的 /usr/share/pacman/PKGBUILD-vcs.proto 原型。

软件包命名

除非软件包获取特定版本，否则在 pkgname 后缀 -bzr、-cvs、-darcs、-git、-hg、-svn 等。

版本控制

如果更改依赖项、URL 或来源后生成的软件包有所不同，请将 pkgver 更新到最新版本。如果自上次更新 PKGBUILD 以来 pkgver 没有更改，请改为增加 pkgrel。

建议采用以下版本格式：RELEASE.rREVISION，其中 REVISION 是单调递增的数字，唯一标识源代码树（VCS 修订版本就是如此）。如果没有公共版本且没有存储库标签，则可以使用零作为版本号，或者您可以完全删除 RELEASE 并使用看起来像 rREVISION 的版本号。如果有公共版本但存储库没有标签，则开发人员应以某种方式获取发行版本，例如通过解析项目文件。

修订号分隔符 — r 紧靠 REVISION 之前 — 非常重要。此分隔符允许避免上游决定进行首次发布或使用具有不同组件数量的版本时出现问题。例如，如果在修订版本 455 时，上游决定发布版本 0.1，则修订版本分隔符会保留版本单调性：0.1.r456 > r454。如果没有分隔符，单调性将失败：0.1.456 < 454。

提示： 可以使用 --holdver 来防止 makepkg 更新 pkgver，请参阅 makepkg(8)。

冲突与依赖

  • 包含软件包冲突和提供的项，例如对于 fluxbox-gitAUR
conflicts=('fluxbox')
provides=("fluxbox=${pkgver}")
注意： 有关版本控制的通用建议，请参阅 PKGBUILD#provides，这些建议通常与 VCS 软件包相关。
  • replaces=() 通常会导致不必要的问题，应避免使用。
  • 在 makedepends=() 中包含适当的 VCS 工具 — cvs、subversion、git 等。

身份验证与安全

  • 使用 cvsroot 时，使用 anonymous:@ 而不是 anonymous@，以避免必须输入空白密码；如果需要密码，则使用 anonymous:password@。
  • 由于来源不是静态的，因此通过添加 'SKIP' 跳过 sha256sums=() 中的校验和。

VCS 来源

注意： 自愿不支持使用稀疏或浅克隆，请参阅 FS#34677 和 邮件列表。

VCS 来源应在 source 数组中指定，并将像任何其他来源一样处理。makepkg 将克隆/检出/分支存储库到 $SRCDEST — 如果未在 makepkg.conf(5) 中设置，则与 $startdir 相同，并将其复制到 $srcdir（以特定于每个 VCS 的方式）。本地存储库保持不变，因此无需 -build 目录。

source 数组的通用格式为

source=('[folder::][vcs+]url[#fragment]')
  • folder（可选）— 用于将默认存储库名称更改为更相关的名称，例如，而不是 trunk，或保留以前的来源。
  • 对于不反映 VCS 类型的 URL，例如 git+https://some_repo，需要 vcs+。
  • url 是到远程或本地存储库的 URL。
  • #fragment（可选）— 需要用于拉取特定分支或提交。有关受支持的 VCS 和可用的相应片段列表，请参阅 PKGBUILD(5) § USING VCS SOURCES。

Git 来源数组示例

source=('project_name::git+https://project_url#branch=project_branch')
警告： 确保不要在 folder 字段中使用 pkgver 变量，因为该变量可能会在 pkgver() 函数调用期间更改，这将导致无法在后续函数中访问创建的文件夹。

pkgver() 函数

pkgver 自动递增现在通过专用的 pkgver() 函数实现。这可以更好地控制 pkgver，维护人员应倾向于使用有意义的 pkgver。要使用 pkgver()，您仍然需要使用最新值声明 pkgver 变量。makepkg 将调用函数 pkgver()，并相应地更新变量 pkgver。

Bazaar

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

Git

使用可从上次提交访问的最新带注释标签

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

使用可从上次提交访问的最新未带注释标签

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

如果 git-tag(1) 不包含破折号，则可以使用更简单的 sed(1) 表达式 sed 's/-/.r/;s/-/./'。

如果标签包含前缀（如 v 或项目名称），则应将其截断

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

如果没有标签，则使用自历史记录开始以来的修订版本号

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

版本和仅提交/修订版本号（SHA-1 已省略；但是，如果未注意版本控制，则在没有 SHA-1 的情况下，快速引用确切的修订版本将会丢失）

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

这两种方法也可以组合使用，以支持最初没有标签但稍后获得标签的存储库（使用 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

Mercurial

pkgver() {
  cd "$pkgname"
  printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)"
}
r2813.75881cc5391e

Subversion

pkgver() {
  cd "$pkgname"
  local ver="$(svnversion)"
  printf "r%s" "${ver//[[:alpha:]]}"
}
r8546
注意： 如果项目有发行版本，则应使用它们而不是 0.。

回退方案

如果无法从存储库中提取令人满意的 pkgver，则可以使用当前的 date(1)

pkgver() {
  date +%Y%m%d
}
20130408
注意： 它不能唯一标识源代码树状态，因此如果可能，请避免使用它。

技巧与诀窍

Git 子模块

Git 子模块有点棘手。其想法是将子模块本身的 URL 直接添加到 sources 数组中，然后在 prepare() 期间引用它们。

下游项目开发人员可能不会将他们的子模块命名为与上游模块的存储库相同的名称。要查看 Git 子模块的名称，请转到项目存储库中的 .gitmodules 文件并预览它。例如，上游开发人员命名的存储库 lib-dependency 可以在下游的 .gitmodules 中注册为名为 libs/libdep 的子模块。

[submodule "libs/libdep"]
  path = libs/libdep
  url = https://example.org/lib-dependency/lib-dependency.git

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
}

Git LFS

Git LFS 需要一些额外的设置

makedepends=(... 'git-lfs')

prepare() {
  git lfs install --local
  git remote add network-origin https://example.org/upstream/lfs/repo
  git lfs fetch network-origin
  git lfs checkout
}

当 LFS 在子模块中使用时，这也有效

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

  git -C libs/libdep lfs install --local
  git -C libs/libdep remote add network-origin https://example.org/upstream/lfs/repo
  git -C libs/libdep lfs fetch network-origin
  git -C libs/libdep lfs checkout
}

Git 校验和

当通过 git+https://domain.invalid/repository.git#tag=v1.0.0 引用稳定的 git 标签或特定提交作为来源时，可以在 PKGBUILD 中指定它们的校验和。为此，只需使用 makepkg -g 或 updatepkgsums 生成它们，就像对任何其他非 git 来源一样。

Retrieved from "https://wiki.archlinux.org.cn/index.php?title=VCS_package_guidelines&oldid=826458"