GLEP 17：解决老旧 EBuild 的方案

摘要

Gentoo 的 Portage 中的许多 ebuild 脚本都是通过 Gentoo 的 Bugzilla 接口由用户提交的。然而，Bugzilla 中还有大量的未完成的 ebuild 请求。本 GLEP 试图解决这些请求。

状态

超时

动机

截至本 GLEP 的第一稿，Gentoo 的 bugzilla 数据库中存在 1517 个 EBUILD 漏洞请求。这些请求通常分为三类

1. 该软件包对 Gentoo 用户很重要，但尚未进入 Portage。

2. 该软件包对 Gentoo 用户来说大多不重要
3. 漏洞请求中未提供 ebuild。

将这些请求保持打开状态无助于 Gentoo。不仅漏洞数量被人工夸大，而且漏洞维护也变得更加困难，增加了开发者必须筛选的开放请求数量。

此外，制定有关如何处理 ebuild 漏洞请求的策略对于一致性和问责制至关重要。

理由

Portage 无法为所有可用的软件包包含自动化的 ebuild。包含的 Ebuild 主要基于开发者的兴趣和知识。许多软件包仅对一小部分最终用户感兴趣，因此将其包含在 Portage 中将是一种资源浪费。

实现

此实现仅适用于在数据库中闲置了一段时间的请求。建议的时间是 90 天。

在此期限后，应按照以下方式处理这些漏洞：

• 应将漏洞关闭为 WONTFIX
• 应在描述中包含以下说明：在请求后 90 天内，没有开发者赞助 ebuild。根据 GLEP 策略 #xx 关闭

影响

对将 ebuild 纳入 Portage 树的（系统性）拒绝可能会让一些用户感到失望，因为他们的 ebuild 未被接受进入 Portage。这是依赖于接受或拒绝的系统的负面影响。

未来

可能需要提供一个官方的存储库来存放被放弃的 ebuild。这些漏洞报告的任何附件都可以放在这里，这样作者的努力就不会白费。

向后兼容性

目前没有与本文档冲突的现有策略。

参考文献

版权

本作品采用知识共享署名-相同方式共享 3.0 未本地化版本许可协议授权。若要查看该许可协议的副本，请访问 https://creativecommons.org/licenses/by-sa/3.0/。