GLEP 65：安装后质量保证检查

质量保证检查类型

此规范中定义了两种质量保证检查

1. 安装后质量保证检查（install-qa-check.d),
2. 合并后质量保证检查（postinst-qa-check.d).

安装后质量保证检查在src_installebuild 阶段完成后但在构建二进制软件包或执行pkg_preinst阶段之前执行。它们可以使用与在src_install中允许的相同的命令，并访问安装映像${D}和临时目录${T}.

如果出现严重的质量保证问题，则允许这些检查更改安装映像的内容以对其进行清理，或调用die函数以中止构建。

合并后质量保证检查在pkg_postinstebuild 阶段完成后执行。它们可以使用与在pkg_postinst中允许的相同的命令，并访问已安装的系统位置${ROOT}和临时目录${T}.

允许这些检查更改文件系统内容的程度与pkg_postinst阶段相同。它们不得调用die.

质量保证检查文件格式和位置

质量保证检查存储为 bash 脚本。检查通过文件名识别和排序。如果在多个位置存在具有相同名称的文件，则使用优先级最高的位置中的文件。

规范定义了四个质量保证检查来源，按优先级递增的顺序列出

1. 包含在软件包管理器中的内部检查，
2. 特定于存储库的质量保证检查，
3. 软件包安装的质量保证检查，
4. 系统管理员定义的质量保证检查。

内部检查存储在特定于软件包管理器的地址中，应与软件包管理器一起安装。建议仅在软件包管理器中包含通用检查，而不是特定于 Gentoo 策略、软件包或包含在 Gentoo 中的 eclass 的检查。

特定于存储库的质量保证检查包含在metadata/install-qa-check.d和metadata/postinst-qa-check.d存储库的目录中。对于相关的 ebuild，会遍历包含它的存储库及其主存储库以查找质量保证检查，并且优先级随着每个继承级别的增加而降低。

软件包安装的质量保证检查位于/usr/lib/install-qa-check.d和/usr/lib/postinst-qa-check.d中，旨在由软件包安装。系统管理员定义的质量保证检查位于/usr/local/lib/install-qa-check.d和/usr/local/lib/postinst-qa-check.d.

质量保证检查脚本格式

质量保证检查由软件包管理器作为 bash 脚本源代码。质量保证脚本在隔离的子 shell 中运行，因此可以安全地更改环境和更改工作目录。质量保证脚本必须始终以一个以成功退出代码结束的命令结尾。

除了标准 PMS 函数外，还提供了两个附加命令

1. eqawarn将质量保证警告输出给用户，
2. eqatag存储有关质量保证问题的机器可读信息。

允许存储库定义的质量保证检查继承提供检查的存储库或其任何主存储库中的 eclass。与特定存储库中的 ebuild 适用的相同继承规则。源代码 eclass 不会影响最终的 ebuild 元数据或阶段函数。

功能规范

质量保证检查类型

创建这两种质量保证检查是为了解决 ebuild 中的不同类型的常见错误。

安装后质量保证检查可用于在将安装映像合并到活动系统或发布为二进制软件包之前验证安装映像。它们可以解决由 ebuild 代码引起的不同问题，直至并包括src_install，作为这些阶段的任何一部分执行的上游代码以及提供的文件。

合并后质量保证检查可用于在合并软件包及其pkg_postinst阶段执行后验证系统状态。它们主要旨在检测缺少的 postinst 操作，但可以执行其他活动系统完整性检查。

质量保证检查文件格式和位置

质量保证检查的多个位置旨在为各种需求提供最佳覆盖范围。

与软件包管理器一起安装的检查旨在涵盖通用情况以及依赖于软件包管理器内部的其他检查。与其他类别的质量保证检查不同，这些检查仅适用于单个软件包管理器，因此可以使用内部 API。但是，建议谨慎使用此类别。

将检查存储在存储库中允许开发人员将其严格绑定到特定版本的发布版并与相关的策略和/或 eclass 一起更新。特别是，Gentoo 策略和 eclass 强制的规则不必适用于使用 Portage 的其他发布版。

质量保证检查也应用于子存储库（通过masters属性）以及 eclass。这确保了大多数存储库不会丢失质量保证检查。与 eclass 相关的质量保证检查以与 eclass 相同的方式继承。与 eclass 类似，子存储库可以覆盖（或禁用）质量保证检查。

系统范围的质量保证检查提供了与软件包一起安装质量保证检查的机会。过去，一些质量保证检查仅根据外部检查器软件的存在而有条件地运行。相反，软件包可以直接安装自己的质量保证检查。

通过/usr/local进行的管理覆盖是系统范围质量保证检查的自然扩展。此外，系统管理员可以使用它来覆盖或禁用几乎任何其他质量保证检查，无论是内部 Portage 还是存储库范围的检查。

共享 QA 检查还有一个额外的好处，即所有包管理器可以使用统一的 QA 工具。

质量保证检查脚本格式

使用 bash 的目的是与 ebuild 格式相匹配。函数的选择旨在实现包管理器之间的可移植性。

脚本在隔离的子 shell 中运行，以简化检查并降低意外跨脚本问题风险。

由于 bash 的限制，脚本需要以成功的命令作为结果结束。

source foo || die "source failed"

该源调用要么返回脚本中最后一个命令的退出代码，要么在源代码错误的情况下返回不成功的退出代码。为了区分两者，我们需要保证脚本始终成功返回。

额外的eqawarnlog 函数旨在为用户提供重要的用户定向警告和面向开发人员的 QA 问题之间的区别。该eqatag函数旨在以机器可读的格式存储检查结果，以便进一步处理。

继承 eclass 可以重用代码并提高可维护性。这种可能性主要用于 eclass 特定的检查，这些检查可能希望例如从 eclass 获取搜索路径。

继承仅在特定于存储库的位置允许，因为这是可以假定 eclass 可用性的唯一位置。对于系统范围的检查，我们不能假设在处理相关 ebuild 时源存储库可用。

功能规范

eqawarn "The following files are frobnicated incorrectly:"
eqawarn
eqatag -v frobnicate "${files[@]}"
eqawarn
eqawarn "Please consult http://example.com/frobnicate for more details."

* The following files are frobnicated incorrectly:
*
*   /usr/bin/frobnicatee
*   /usr/bin/other-frobnicatee
*
* Please consult http://example.com/frobnicate for more details.