获取 Gentoo！

GLEP 35：ebuild 的自动一致性检查

作者 Adrian Lambeck <adrian@basicsedv.de>
类型 标准跟踪
状态 已延期
版本 1
创建日期 2005-03-12
最后修改日期 2017-11-09
发布历史 2005-03-12
GLEP 源码 glep-0035.rst

摘要

本提案旨在提高 Gentoo 开发人员的生产力。它旨在通过在检查之前执行的一致性检查以及定期对整个树进行的一致性检查来自动检测这些错误，从而减少微不足道的错误数量。为什么还要费心处理微不足道的错误，当自动化测试可以找到它们时？节省时间并提高质量！

动机

当浏览 bugs.gentoo.org 时，您会发现一些错误会占用大量宝贵的开发时间，而这些时间本可以用于其他用途。这些是微不足道的错误，例如错误的 SRC_URI 或 DEPEND 中的循环。更糟糕的是 - 这些错误有时会被多次报告，因此需要将其标记为重复错误。此类错误很容易找到也很容易修复。通过定期使用自动检查，可以找到这些错误。需要要求用户不要将这些错误提交到 bugs.gentoo.org。因此（希望）需要检查和分配的错误会更少，并且修复速度可能会更快。

找到的错误应保存在自动生成的列表中，以便用户可以看到问题已被捕获并正在处理。

规范

需要对每个 ebuild 进行检查。

需要生成一份报告。

  • 需要包含指向特定问题的链接。
  • 需要将报告发送给负责的组。

检查内容可以包括：

  • DEPEND 中的循环
  • 无效的 SRC_URI
  • “非官方”USE 标记
  • DEPEND 中针对指定架构为“*”的软件包
  • 带有无效或缺少命令的损坏的 shell 脚本
  • eclass 的继承
  • ...

可能还有其他尚未想到的需要运行的检查和测试。此外，我可能建议了一些完全没有用的东西。

如果 ebuild 中存在重大问题（需要定义），则可能的措施可能是禁用 ebuild（使用"-*"），也许，并向维护者发送邮件。

这些类型的错误并不总是开发人员的错。

不应该进行编译或类似操作。如果某个 ebuild 在某个地方构建失败，则用户应像往常一样将其作为错误提交。

实现

所描述的功能可以通过三种方式实现：

  1. 在开发人员的机器（“客户端”）上，在检查之前运行。
    仅针对已更改的 ebuild。（客户端不适合这里，因为服务器和客户端根本不应该相互通信）
  2. 在服务器上运行检查，例如每周一次。
  3. 在“客户端”和服务器上

当然，存在利弊（到目前为止我想到的）

  1. 优点
    • 树木首先无法变得不一致（？请参阅缺点）
    • 检查 ebuild 后，无需再次执行此操作
    • 不需要专用的机器
    • 在一台机器上仅生成一次流量
    • 在此处捕获的错误不会在以后造成麻烦
    缺点
    • 一致性基于安装的工具
      （当不同的开发人员使用不同的版本时会发生什么？）
    • 当 ebuild 布局发生变化且某些 ebuild
      未更新时会发生什么？
  2. 优点
    • 在编写 ebuild 时，其他 ebuild 的属性可能会发生变化，从而适合当前情况
    缺点
    • 当 ebuild 已经在 CVS 中时，会发现错误
    • 需要检查整个树
    • 每次运行都可能产生大量流量
      （-> 是否有类似于 HTTP 的 HEAD 的 FTP 等效项？）
  3. 参见 1 和 2。

我最喜欢的是 3。所有属性都在签入前进行检查，并且可能会在服务器上定期检查发生变化的属性。只有解决方案 3 将 1 和 2 的最佳功能结合在一起，同时提供最佳结果。

我从未查看过 portage 源代码，但我可以想象有一个库包含开发人员“查询”ebuild 所需的所有内容。如果没有，这将是另一个 GLEP 的理由（？）

为了提高性能，我将在服务器上使用数据库来存储整个树，然后再运行检查。对于“客户端”来说，这没有必要。

向后兼容性

这对本 GLEP 来说不是问题。