GNOME 软件包指南

Arch Linux 上的 GNOME 软件包遵循特定的模式。

来源 URL

GNOME 软件包通常遵循两种来源 URL 方案：存储在 GNOME FTP 服务器上的已发布 tarball 和软件 Git 仓库中的特定 commit

使用发布的 tarball

当下载发布的 tarball 时，您可以从 https://download.gnome.org 获取，使用以下 source 数组

source=("https://download.gnome.org/sources/$pkgname/${pkgver%.*}/$pkgname-$pkgver.tar.xz")

其中 ${pkgver%.*} 返回 major.minor 软件包版本，方法是删除 pkgver 的后缀（即 micro 软件包版本）。例如，如果 pkgver=3.28.0，则 ${pkgver%.*} 将返回 3.28。

使用 Git 仓库中的 commit

另一种常见的做法是使用 GNOME 软件源代码 git 仓库中的特定 commit 作为来源。它不归类为 VCS 软件包，因为 Pacman 设置特定 commit 的功能（请参阅 PKGBUILD(5) § USING VCS SOURCES）使 PKGBUILD 不会跟踪最新的开发 commit，也不会更新 pkgver 字段，而是使用来自指定 commit 哈希的来源。

请参阅下面的模板

PKGBUILD

url="https://gitlab.gnome.org/GNOME/$pkgname"
makedepends=(git)
_commit=hash_of_a_commit  # tags/X.Y.Z 
source=("git+${url}.git#commit=$_commit")
md5sums=('SKIP')

pkgver() {
  cd $pkgname
  git describe --tags | sed 's/-/+/g'
}

将 hash_of_a_commit 替换为所需的 Git commit 哈希，并替换 pkgver() 语句以适应您要打包的软件包的需求（请参阅 VCS 软件包指南#Git）。

请注意，由于来源是通过 git 下载的，因此 makedepends 中必须包含 git，并且校验和必须设置为 'SKIP'，就像任何其他 VCS 软件包一样。强烈建议使用 pkgver() 函数，以便为提供的 commit 哈希相应地设置 pkgver。

注意： GNOME 之前使用 https://git.gnome.org，但后来迁移到 https://gitlab.gnome.org[1]。旧链接应自动重定向到新的 gitlab.gnome.org 域，但手动更新您的来源 URL 可能是明智之举。

Meson 和 GNU 构建系统

历史上，GNOME 使用 GNU 构建系统 来构建其应用程序。虽然目前仍有一些活跃的应用程序和许多不活跃的应用程序仍在使用 GNU 构建系统，但大多数当前活跃的 GNOME 应用程序已迁移到 Meson 构建系统。

有关适用于大多数 GNOME 应用程序的打包需求的说明，请参阅 Meson 软件包指南。

注意： 即使 GNOME 应用程序是用不同的编程语言编写的，如果这是为该 GNOME 应用程序设置的构建系统，您也应该坚持使用 Meson。例如，不要对用 Rust 语言编写的 GNOME 应用程序使用 Rust 软件包指南，因为您应该使用 meson 而不是 rustc 或 cargo 来构建它。

GSettings 架构

GSettings 是 GNOME 应用程序当前使用的架构，可以使用 GUI 工具 dconf 或 CLI 工具 gsettings（由 glib2 提供，它很可能已作为依赖项安装）访问/读取/编辑。GSettings 过去需要打包者的一些关注，但如今无需干预。

一些观察结果

• 使用 GSettings 的应用程序通常依赖于 GTK（gtk3 或更高版本），因此 GSettings 相关的依赖项通常已经满足。
• 过去需要 ./configure 中的 --disable-schemas-compile 标志来避免在 package() 函数中重新编译 GSettings 数据库，但现在这不再适用于 GNOME 应用程序一段时间了，主要是在使用 Meson 作为构建系统的应用程序中。

警告： 即使对于旧的、非 Meson GNOME 应用程序，也不要在 .install 文件中调用 glib-compile-schemas，因为自 glib2=2.48.0-2 以来，GSettings 架构数据库已通过 pacman hooks 自动重新编译。

GConf 架构

大多数 GNOME 软件包已从 GConf 架构 迁移到 #GSettings 架构，但您可能会遇到安装这些 GConf 架构的旧式且过时的 GNOME 软件包。在这些情况下，必须将 gconf^AUR 添加到 depends 数组中。

Gconf 架构安装在系统 GConf 数据库中，这是必须避免的。某些软件包为 ./configure 提供了 --disable-schemas-install 标志，但这几乎从不奏效。但是，gconftool-2 有一个名为 GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL 的变量，您可以设置该变量来告诉 gconftool-2 不要更新任何数据库。

当创建安装 GConf 架构文件的软件包时，请在 PKGBUILD 的 package() 函数中使用

make GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 DESTDIR="${pkgdir}" install

警告： 不要在 .install 文件中调用 gconfpkg，因为自 gconf^AUR=3.2.6-4 以来，GConf 架构已通过 pacman hooks 自动安装/删除（在安装/删除 GNOME 软件包时）。

ScrollKeeper 文档

如今 GNOME 应用程序不使用 ScrollKeeper，但您可能会遇到带有该文档的基于 GTK2 的应用程序。

自 GNOME 2.20 以来，无需为 ScrollKeeper 运行任何命令，因为 rarian^AUR 直接读取其 OMF 文件。scrollkeeper-update 现在只是一个虚设命令。唯一的要求是将 gnome-doc-utils^AUR 包含在 makedepends 数组中。

您可以使用 ./configure 中的 --disable-scrollkeeper 标志禁用文档生成。

GTK 图标缓存

许多图形化 GNOME 应用程序在系统中安装图标，这些图标通过 gtk-update-icon-cache 工具包含在图标缓存中。每次添加或删除图标时，都会使用此工具更新缓存。

注意

• 不要在 .install 文件中调用 gtk-update-icon-cache 工具，因为自 gtk-update-icon-cache=3.20.3-2 以来，图标缓存已通过 pacman hooks 更新。
• 软件包不需要依赖 gtk-update-icon-cache，因为诸如 gtk4 等软件包将满足此依赖项。

.desktop 文件

许多软件包安装与 Freedesktop.org 兼容的 .desktop 文件，并在其中注册 MimeType 条目。这些信息存储在一个数据库中，每次添加或删除时都必须更新该数据库。这是 update-desktop-database 工具的功能。

注意

• 不要在 .install 文件中调用 update-desktop-database，因为自 desktop-file-utils=0.22-2 以来，数据库已通过 pacman hooks 自动更新。
• 软件包不需要依赖 desktop-file-utils，因为诸如 gtk4 等软件包将满足此依赖项。

AppStream 和 metainfo 文件

与许多其他应用程序一样，大多数 GNOME 应用程序都遵循 Freedesktop.org 的 AppStream 规范 并提供 metainfo 文件，以便应用程序的描述显示在应用程序中心中，例如 gnome-software 或 Flathub。

如果 check() 函数中调用 meson test 时存在 appstream-util 工具，GNOME 应用程序通常会验证 metainfo 文件。如果未安装 appstream-glib，则只会阻止执行此特定验证（即，不会有错误中断构建过程）。

您可以使用两种方法来识别应用程序是否使用了 appstream-util

• 第一种方法是通过运行 grep -R appstream-util 或查看 data/meson.build 文件来在源代码中查找 appstream-util；
• 另一种方法是读取构建过程以查找

  Program appstream-util found: NO

将 appstream-glib 添加到 checkdepends 数组以验证 metainfo 文件。