Arch 软件包指南

来自 ArchWiki
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

相关文章

当为 Arch Linux 构建软件包时，请遵守以下软件包指南，特别是当您打算向 Arch Linux 贡献新软件包时。您还应该查看 PKGBUILD(5) 和 makepkg(8) man 手册页。

此页面上列出的要点不会在其他软件包指南页面上重复。这些具体指南旨在作为对以下列出的标准的补充。

提交到 Arch 用户仓库 的软件包还必须遵守 AUR 提交指南。

请参阅 /usr/share/pacman/ 目录 中的 .proto 文件作为 PKGBUILD 示例。

软件包礼仪

  • 软件包绝不应安装到 /usr/local/。
  • 不要在 PKGBUILD 构建脚本中引入新的变量或函数，除非不这样做就无法构建软件包，因为这些变量和函数可能会与 makepkg 本身使用的变量和函数冲突。
  • 如果绝对需要新的变量或新的函数，请在其名称前加上下划线 (_)，例如
    _customvariable=
  • 避免为任何事物使用 /usr/libexec/。请改用 /usr/lib/$pkgname/。
  • 软件包构建者可以通过修改 /etc/makepkg.conf 文件中的相应选项来自定义软件包元文件中的 packager 字段，或者通过创建 ~/.makepkg.conf 来覆盖它。
  • 不要使用 makepkg 子例程（例如 error、msg、msg2、plain、warning），因为它们可能随时更改。要打印数据，请使用 printf 或 echo。
  • 所有重要消息都应在使用 .install 文件安装期间回显。例如，如果软件包需要额外的设置才能工作，则应包含说明。
  • 依赖关系是最常见的软件包错误。请花时间仔细验证它们，例如通过在动态可执行文件上运行 ldd，检查脚本所需的工具或查看软件的文档。namcap 实用程序可以帮助您在这方面。此工具可以分析 PKGBUILD 和生成的软件包 tarball，并将警告您关于错误的权限、缺失的依赖项、冗余的依赖项和其他常见错误。
  • 任何可选依赖项，如果不是运行软件包或使其通常运行所必需的，则不应包含在 depends 数组中；而应将信息添加到 optdepends 数组中
optdepends=('cups: printing support'
            'sane: scanners support'
            'libgphoto2: digital cameras support'
            'alsa-lib: sound support'
            'giflib: GIF images support'
            'libjpeg: JPEG images support'
            'libpng: PNG images support')
以上示例取自 wine 软件包。optdepends 信息在安装/升级时自动打印出来，因此不应将此类信息保存在 .install 文件中。
  • 在为软件包创建软件包描述时，请勿以自引用的方式包含软件包名称。例如，“Nedit 是一个用于 X11 的文本编辑器”可以简化为“一个用于 X11 的文本编辑器”。另请尝试将描述保持在 ~80 个字符或更少。
  • 尝试将 PKGBUILD 中的行长度保持在 ~100 个字符以下。
  • 在可能的情况下，从 PKGBUILD 中删除空行（provides、replaces 等）
  • 通常的做法是保留 PKGBUILD 文章中给出的相同顺序的 PKGBUILD 字段的顺序。但是，这不是强制性的，因为在这种情况下，唯一的要求是正确的 Bash 语法。
  • 引用可能包含空格的变量，例如 "$pkgdir" 和 "$srcdir"。

软件包命名

  • 软件包名称只能包含字母数字字符以及 @、.、_、+、- 中的任何字符。名称不允许以连字符或点开头。所有字母都应为小写。
  • 软件包名称不应带有上游主要版本号后缀（例如，如果上游将其称为 libfoo v2.3.4，我们不希望使用 libfoo2），以防库及其依赖项有望能够继续使用每个上游版本各自的最新库版本。但是，对于某些软件或依赖项，不能假设这一点。过去，对于小部件工具包（如 GTK 和 Qt）尤其如此。依赖于此类工具包的软件通常无法轻松移植到新的主要版本。因此，在软件无法轻松地与其依赖项一起滚动的情况下，软件包名称应带有主要版本后缀（例如 gtk2、gtk3、qt4、qt5）。对于大多数依赖项可以与最新版本一起滚动，但有些不能（例如，需要 libpng12 或类似版本的闭源），该软件包的已弃用版本可能称为 libfoo1，而当前版本仅为 libfoo。

软件包版本控制

  • 软件包 版本 — pkgver — 应与作者发布的版本相同。
  • 如果需要，版本可以包含字母，例如，版本可以是 2.54BETA32。
  • 版本标签可能不包含连字符，并且可能仅包含字母、数字和句点。如果上游版本包含连字符，则必须将其替换为下划线。


  • 软件包 发行版 — pkgrel — 是 Arch Linux 软件包特有的。这些允许用户区分较新和较旧的软件包构建。当首次发布新软件包版本时，发行计数从 1 开始。然后，随着修复和优化的进行，软件包将重新发布到 Arch Linux 公众，并且发行版号将递增。
  • 当新版本发布时，发行计数将重置为 1。
  • 软件包发行版标签遵循与版本标签相同的命名限制。

软件包依赖

软件包关系

软件包来源

  • 应尽可能使用 HTTPS 来源（tarball 使用 https://，git 来源使用 git+https://）
  • 应尽可能使用 PGP 签名验证来源（如果上游对提交和标签进行签名，但不对 tarball 进行签名，则这可能需要从 git 标签而不是源 tarball 构建）

本文或本节内容的准确性存在争议。

原因： 在最近的 pacman 中，commit# 不是必需的，因为 git 来源支持正确的校验和。请参阅[1]。gitea 软件包也已更新为使用以下方法（在 Talk:Arch package guidelines 中讨论）
  • 从 git 标签构建时，请使用从 git rev-parse 获取的对象哈希而不是标签名称
_tag=1234567890123456789012345678901234567890 # git rev-parse "v$pkgver"
source=(git+https://$url.git?signed#tag=$_tag)

pkgver() {
    cd "$pkgname"
    git describe
}
可以在 gitea 软件包中找到此方法的示例。这种做法的原因是标签可以被强制推送以更改它们指向的提交，这将改变构建的软件包。使用标签对象哈希可确保来源的完整性，因为强制推送标签会更改其哈希。使用 pkgver() 函数可防止意外地在不更新 _tag 的情况下增加 pkgver。有关 VCS 来源格式的更多信息，请参阅 VCS 软件包指南#VCS 来源。
  • 不要降低软件包的安全性或有效性（例如，通过删除校验和检查或删除 PGP 签名验证），因为上游版本已损坏或突然缺少某些功能（例如，新版本缺少 PGP 签名）
  • 来源在 srcdir 中必须是唯一的（这可能需要在下载时重命名它们，例如 "${pkgname}-${pkgver}.tar.gz::https://${pkgname}.tld/download/${pkgver}.tar.gz"）
  • 避免使用特定的镜像（例如，sourceforge）进行下载，因为它们可能变得不可用

与上游合作

被认为是最佳实践是在可能的情况下与上游密切合作。这包括报告关于构建和测试软件包的问题。

  • 立即向上游报告问题。
  • 尽可能向上游提交补丁。
  • 在 PKGBUILD 中添加带有相关（上游）错误跟踪器票证链接的注释（这尤其重要，因为它确保其他打包者可以理解更改并也可以使用软件包）。

建议使用 nvchecker、nvrsAUR 或 urlwatch 等工具跟踪上游，以便及时了解新的稳定版本。

目录

  • 配置文件应放置在 /etc 目录中。如果存在多个配置文件，则习惯上使用子目录，以使 /etc 区域尽可能干净。使用 /etc/pkg，其中 pkg 是软件包的名称（或合适的替代名称，例如，apache 使用 /etc/httpd/）。
  • 软件包文件应遵循这些通用目录指南
/etc 系统必需的配置文件
/usr/bin 二进制文件
/usr/lib 库
/usr/include 头文件
/usr/lib/pkg 模块、插件等。
/usr/share/doc/pkg 应用程序文档
/usr/share/info GNU Info 系统文件
/usr/share/licenses/pkg 应用程序许可证
/usr/share/man Manpages
/usr/share/pkg 应用程序数据
/var/lib/pkg 持久性应用程序存储
/etc/pkg pkg 的配置文件
/opt/pkg 大型自包含软件包
  • 软件包不应包含以下任何目录
    • /bin
    • /sbin
    • /dev
    • /home
    • /srv
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp
    • /run

Makepkg 职责

当使用 makepkg 构建软件包时，它会自动执行以下操作

  1. 检查是否已安装软件包依赖项和 makedepends
  2. 从服务器下载源文件
  3. 检查源文件的完整性
  4. 解压源文件
  5. 执行任何必要的补丁
  6. 构建软件并将其安装在伪根目录中
  7. 剥离二进制文件中的符号
  8. 剥离库中的调试符号
  9. 压缩手册和/或信息页面
  10. 生成包含在每个软件包中的软件包元文件
  11. 将伪根目录压缩到软件包文件中
  12. 将软件包文件存储在配置的目标目录中（即，默认情况下为当前工作目录）

架构

如果编译后的软件包是特定于架构的，则 arch 数组应包含 'x86_64'。否则，对于与架构无关的软件包，请使用 'any'。

许可证

请参阅 PKGBUILD#license。

可重现构建

Arch 正在努力使所有软件包都实现 可重现。打包者可以使用 devtools 中的 makerepropkg 或 archlinux-repro 中的 repro 检查软件包是否可重现。

$ makerepropkg $pkgname-1-1-any.pkg.tar.zst

或者

$ repro -f $pkgname-1-1-any.pkg.tar.zst

如果在构建时需要时间戳，请使用环境变量 SOURCE_DATE_EPOCH。格式在 上游文档 中进行了说明。

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