pkgbuilds

Garuda Linux PKGBUILD

该存储库包含当前驻留在其garuda存储库中的所有软件包的 PKGBUILD。由于广泛使用其 CI，它在 GitLab 上运行，并拥有只读的 GitHub 镜像。

本回购协议的范围

我们自己的所有 PKGBUILD 都包含在这里。从历史上看，它们被分成自己的存储库。为了更容易地找到正确的 PKGBUILD，并允许更快地贡献，我们最近将它们合并到这个新的存储库中。包括所有包的 PKGBUILD，包括它们的配置文件（这适用于像garuda-fish-config这样的较小文件）。对于其中一些包，例如garuda-*-settings包，其内容仍然可以在其各自的存储库中找到。

发现任何问题吗？

如果发生任何包装问题或类似问题，请随时通过我们的问题部分报告。您可以单击此处创建一个新的。

如何贡献？

我们非常感谢任何形式的贡献！ ？为此，请按照下列步骤操作：

• 创建此存储库的一个分支。
• 在本地克隆你的 fork（简短的 git 教程）。
• 将所需的更改添加到 PKGBUILD 或源代码中。
• 确保 shellcheck 和 shfmt 报告更改的文件没有问题
  • 需要先安装所需的依赖项，例如。通过sudo pacman -S shfmt shellcheck
  • 通过 bash 运行lint.sh脚本bash ./.ci/lint.sh检查代码
  • 通过bash ./ci/lint.sh apply
• 使用传统的提交消息进行提交，并将任何更改推送回您的分支。
  • commitizen 应用程序有助于创建合适的提交消息。您可以通过 pip 安装它，因为 Arch 存储库中当前没有软件包： pip install --user -U Commitizen 。然后在克隆的文件夹中运行cz commit继续。
• 在我们的主存储库中创建一个新的合并请求。
• 检查是否有任何管道运行失败并应用最终建议。

然后我们将审查更改并最终合并它们。

处理某些包装问题

已弃用和损坏的包

在某些情况下，已弃用的软件包不再有任何用途，还会导致系统无法更新。这些可以通过将包添加到garuda-common-settings的conflicts()和garuda-update的 auto-pacman 来处理。结果是有问题的包由于冲突而被自动删除。

CI/构建工具

以下内容部分取自构建工具文档，省略了与本存储库无关的信息。如果您正在寻找安装说明，请参阅完整的自述文件。

一般的

可以通过更改 PKGBUILD 目录内的内容或将[deploy *]附加到提交消息来自动触发部署。与 PKGBUILD 检查不同，这些检查仅适用于main分支上的提交。支持的有：

• [deploy all] ：部署完整的garuda例程，意味着此存储库中的所有 PKGBUILD。
• [deploy $pkgname] ：部署包pkgname ，这意味着通过将其替换为garuda-bash-settings ，可以部署garuda-bash-settings 。

一旦检测到任何这些组合，部署就会在成功完成一些检查后开始。可以通过“管道”部分检查过去部署的日志。

自动颠簸

该存储库提供半小时一次的管道，如果其源驻留在另一个存储库中，则根据最新的可用标签，将所有 PKGBUILD 更新到最新版本。然后它继续更新校验和并将更改推送回主分支。通过将[deploy *]附加到提交消息，会自动触发新的部署。这意味着推送新标签就足以触发这些包的新包版本的部署。重要通知：

• 这不适用于所有文件都在此存储库中的包
• 标签不得以v为前缀
• 有关包源的所需信息通过 SOURCES 文件提供。每行都遵循方案$url $pkgname $project_id 。后者用于通过 GitLab API 检索最新标签，可以在存储库的常规设置页面找到。

可以通过浏览管道部分来检查该作业的最新运行情况，带有计划标记的每个管道都由计时器执行。此外，可以通过浏览管道计划部分并点击运行管道计划来手动触发管道。

手动更新版本

对于某些 PKGBUILD，例如garuda-fish-config ，所有文件都驻留在此存储库中。更新 PKGBUILD 时，请确保同时更新相应的.SRCINFO文件，因为该文件用于解析所有包相关信息！

添加包

添加包就像创建一个以包的$pkgbase命名的新文件夹一样简单。将 PKGBUILD 和所有其他必需的文件放在这里。因此，添加 AUR 包就像克隆其存储库并删除.git文件夹一样简单。 CI 依赖.SRCINFO文件来解析大多数信息，因此，对于自我管理的包来说，将它们放置到位并保持最新非常重要。最后，添加一个包含基本配置的.CI文件夹（需要CI_PKGBUILD_SOURCE ，以防其外部包，自我管理的 PKBUILD 不需要它），提交任何更改，并将更改推送回主分支。这样做时请遵循传统的提交约定（cz-cli 可以帮助解决这个问题！）。这意味着提交如下：

• feat($pkgname): init
• fix($pkgname): fix xyz
• chore($pkgname): update PKGBUILD
• ci(config): update

这不仅有助于拥有统一的提交历史记录，还允许自动生成变更日志。

删除包

这可以通过删除包含包的 PKGBUILD 的文件夹来完成。然后，清理作业将通过on-commit管道运行自动删除任何过时的包。这还将考虑包可能生成的任何拆分包。重命名文件夹也算作删除包。

提交管道

每当推送新的提交时，CI 管道都会执行以下操作：

• 检查最后一个scheduled标签的创建时间。这用于确定需要安排哪些包。
• 它解析每个提交的[deploy $foldername]字符串，仅接受从现有 PKGBUILD 文件夹派生的有效值。 [deploy all]也是一个有效参数。 $pkgname拼写错误是一个致命错误。任何问题都必须解决并强制推动。
• 然后，解析更改的文件。这还包括已删除的软件包。任何更改的相关文件夹内容都会导致相应包的包部署。
• 最后的操作是构建计划参数（通过工件将其移交给计划作业）并删除所有过时的包，以防检测到较早的步骤。
• 如果所有这些操作都成功， scheduled标记就会更新，因此我们可以在以后的管道运行中引用它。

管道按计划进行

半小时一班

每半小时，正点管道就会执行一些任务：

• 从模板存储库更新 CI 模板（如果通过.ci/config启用）
• 检查计划标签是否不存在或计划未指向 HEAD（在这种情况下中止任务！）
• 检查包含包状态的 .state 工作树是否存在，如果存在，则设置它。否则，它会从头开始重新创建它（例如，在强制推送时）
• 检查最后一次提交是否是自动的（包含“chore（packages）：更新包[skip ci]”），如果是，则计划产生的提交将覆盖它以保持提交历史记录干净。
• 收集包的 AUR 时间戳以确定 PKGBUILD 是否发生更改
• 循环遍历每个有效包并执行以下操作：
  • 读取.CI/config文件以获取有关包配置的信息（例如，是否管理 AUR 存储库、PKGBUILD 的来源等）
  • 在以下情况下更新 PKGBUILD：
    • CI_PKGBUILD_SOURCE 设置为gitlab ：从 GitLab 存储库标签更新 PKGBUILD
    • CI_PKGBUILD_SOURCE 设置为aur ：从 AUR 存储库更新 PKGBUILD，拉入 git 存储库并用新文件替换现有文件。如果无法提前收集 AUR 时间戳，则会跳过包更新。
    • CI_PKGBUILD_SOURCE 未设置为gitlab或aur ：尝试通过拉取 CI_PKGBUILD_SOURCE 中指定的存储库来更新 PKGBUILD。如果两次尝试后克隆未成功，则会跳过更新过程。
  • 如果在包配置变量中设置了 CI_GIT_COMMIT，则更新 PKGBUILD source部分中设置的 git URL 的最新提交。如果不同，请安排构建。
  • 如果存在自定义挂钩（包目录内的.CI/update.sh ），它将被执行 - 这可用于使用自定义脚本更新 PKGBUILD。
  • 将所需的变量写回.CI/config （例如 Git 哈希）
• 如果发生较小的更改，则静默更新 PKGBUILD；如果发生重大更新，则创建 PR 进行审查（并且仅当CI_HUMAN_REVIEW为 true 时）
  • 仅当 diff 实际报告当前 PKGBUILD 文件夹和 AUR PKGBUILD 存储库之间的更改时才考虑更新
  • 检测到对源文件所做的任何更改，但这不会检测到包构建的上游项目源中的恶意更改
• 状态工作树已更新为新信息
• 计划参数正在构建并通过工件移交给计划作业
• 过时的分支（例如合并审查 PR）正在被修剪
• 预定标签再次更新

日常的

已为动态生成其pkgver的特定软件包添加了每日管道计划。要使用它，请在包的.CI/config文件中设置CI_ON_TRIGGER=daily 。

手动调度

无需 git 提交即可调度包

可以通过转到管道运行页面，选择“运行管道”并将PACKAGES添加为变量并将包名称作为其值，将包手动添加到计划中。然后管道将拾取包裹并安排它们。 PACKAGES还可以设置为all以安排所有包。如果要安排一个或多个软件包，则需要遵循pkgname1:pkgname2:pkgname3格式。

按需运行预定的管道

这可以通过转到管道运行页面，选择“运行管道”（播放符号）来完成。将提供管道页面的链接，可以在其中获取管道日志。

添加干扰

将所需的干扰文件放入 PKGBUILD 文件夹的.CI文件夹中：

• prepare ：在建立构建 chroot 后执行的脚本。它可用于在编译开始之前获取环境变量或修改其他内容。
  • 如果在实际编译过程之前需要设置某些内容，可以通过插入例如来推送命令。 $CAUR_PUSH 'source /etc/profile' 。同样，可以解决包冲突，例如。如下： $CAUR_PUSH 'yes | pacman -S nftables' （单引号很重要，因为我们希望变量/管道在来宾运行时进行计算，而不是在干扰时进行计算）
• interfere.patch ：一个补丁文件，可用于修复多个文件或 PKGBUILD（如果需要进行大量更改）。所有更改都需要添加到此文件中。
• PKGBUILD.prepend ：此文件的内容被添加到 PKGBUILD 的开头。
• PKGBUILD.append ：此文件的内容添加到 PKGBUILD 的末尾。修复build()就像将修复的build()添加到此文件中一样简单。这可用于各种修复。如果需要将某些内容添加到数组中，这就像makedepend+=(somepackage)一样简单。
• on-failure.sh ：构建失败时正在执行的脚本。
• on-success.sh ：构建成功时正在执行的脚本。

碰撞 pkgrel

现在通过将所需的变量CI_PACKAGE_BUMP添加到.CI/config来执行此操作。请参阅下文了解更多信息。

依赖树

CI 自动构建依赖关系树。它们作为 CI 工件传递给 Chaotic 管理器，并在执行计划命令时读取。无需人工干预。

.CI/配置

每个包目录中的.CI/config文件包含用于控制管道和构建进程的附加标志。

• CI_MANAGE_AUR ：通过将此变量设置为true ，如果发生更改，CI 将在管道运行结束时更新相应的 AUR 存储库（忽略 CI 相关文件）
• CI_PACKAGE_BUMP ：控制所有未将CI_MANAGE_AUR设置为true包的包碰撞。该变量每增加+1 ， pkgrel就会增加0.1 。
• CI_PKGBUILD_SOURCE ：设置所有 PKGBUILD 相关文件的源，用于从远程存储库提取更新的文件。目前有效值为：
  • gitlab ：从 GitLab 存储库标签中提取 PKGBUILD。它需要遵循格式gitlab:$PROJECT_ID 。可以通过浏览存储库设置常规部分来获取该 ID。
  • aur ：从 AUR 存储库中提取 PKGBUILD，提取 git 存储库并用新文件替换现有文件。
• CI_ON_TRIGGER ：可以在特殊调度触发器应调度相应包的情况下提供。通过将值设置为daily ，可以用于每天安排包。由于这会检查是否“$TRIGGER == $CI_ON_TRIGGER”，因此可以使用管道计划并将TRIGGER设置为midnight来创建任何自定义计划，添加拟合计划并将任何受影响的包的CI_ON_TRIGGER设置为midnight 。
• CI_REBUILD_TRIGGERS ：添加已知会导致此变量重建的包。通过存储库的CI_LIB_DB参数提供用于跟踪包版本的存储库列表。每个包版本都经过哈希处理并转储到.ci/lib.state 。每个计划的管道运行都会通过检查哈希不匹配来比较版本，并将通过CI_PACKAGE_BUMP碰撞每个受影响的包。
• BUILDER_CACHE_SOURCES ：如果源应该在构建之间缓存，则可以设置为true 。这在源速度慢或源并非始终可用的情况下非常有用。源将在 1 个月后自动清除，这在软件包被删除或源发生更改时非常重要。

管理 AUR 包

AUR 包还可以使用.CI_CONFIG通过此存储库以自动化方式进行管理。这意味着在每个计划和提交管道之后，AUR 存储库将更新以反映对 PKGBUILD 文件夹文件所做的更改。与 AUR 维护无关的文件（例如.CI文件夹）将被省略。提交消息反映了提交是由 CI 管道创建的事实，并且包含指向源存储库的提交历史记录和触发更新提交的管道运行的链接。

更新 CI 的脚本

这是通过 CI 管道自动完成的。一旦在模板存储库上检测到更改，所有文件都将更新到当前版本。

问题和管道故障

上次提交管道失败

如果有多种原因，例如提供了无效的包名称，则可能会发生这种情况。这会导致scheduled标记无法更新。在这种情况下，按计划进行的管道将无法运行。在按计划管道可以再次运行之前，需要修复最后一个按提交管道。然而，构建失败不会被考虑，因为一旦生成调度参数， scheduled标签就会被更新。在这种情况下，积极鼓励强制推送已修复的提交，因为推送另一个提交将导致 CI​​ 评估它错过的先前提交，从而导致再次注意到相同的问题并退出，而不是默默地继续。这是为了防止忽视故障而做出的设计决策。

重置构建队列

在极少数情况下，可能需要重置构建队列。这可以通过关闭中央 Redis 实例、删除其转储并重新启动其服务来完成。

混乱的经理

该工具作为 Docker 容器分发，由一对管理器和构建器实例组成。

• 管理器： registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
• 生成器： registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
  • 这包含了从 infra 3.0 中已知的包构建背后的实际逻辑（参见此处），例如interfere.sh 、 database.sh等。
  • 选择要从管理器实例管理的 Redis 实例构建的包

该管理器由 GitLab CI 在schedule-package作业中使用，通过将包添加到构建队列来调度包。任何能够运行容器的机器都可以使用该构建器。它将从我们的中央 Redis 实例中选择可用的作业。

开发设置

该存储库具有 NixOS flake，可用于通过 direnv 自动设置所需的内容，例如预提交挂钩和检查以及所需的实用程序。这包括通过shellcheck和shfmt检查 PKGBUILD。需要的是nix （包管理器）和 direnv，之后，可以通过运行direnv allow进入环境。