获取 Gentoo！

GLEP 50：支持替代包管理器

作者 Grant Goodyear <g2boojum@gentoo.org>
类型 标准跟踪
状态 已拒绝
版本 1
创建日期 2006-05-22
上次修改日期 2014-01-23
发布历史 2006-06-15, 2006-09-06
GLEP 源码 glep-0050.rst

状态

委员会拒绝了这份 GLEP，转而从包管理器 API 开始，并要求树中的 Gentoo 包管理器支持该 API。（但是，该 API 仍在等待中。）

摘要

为了支持官方包管理器（在撰写本文时为 Portage）的替代方案，需要制定一些合理的规则。具体来说，除非某个基于 ebuild 的替代包管理器能够成功地与官方包管理器支持的所有 ebuild 一起工作，否则不得将其添加到树中。此外，除非官方包管理器支持（无需更改）某个 ebuild，否则不得将其添加到树中。

规范

  • 除非某个基于 ebuild 的替代包管理器能够成功地与官方包管理器支持的所有 ebuild 一起工作，否则不得将其添加到树中。如果某个替代包管理器在运行时与官方包管理器不兼容，则必须将其屏蔽并提供相应的警告。
  • 除非官方包管理器支持（无需更改）某个 ebuild，否则不得将其添加到树中。

基本原理

第一条规则为将替代包管理器添加到树中设置了一个合理的标准。请注意，如果树中当前的 ebuild 不适用于官方包管理器，则也不期望它适用于替代包管理器。第二条规则确保替代包管理器无法通过支持官方包管理器无法处理的软件包而成为事实上的要求。

为了使本提案尽可能简单和集中，它没有说明替代包管理器将来如何成为官方包管理器的流程。假设会保持理智，并且在任何包管理器能够构建安装介质、提供从现有官方包管理器到现有官方包管理器的转换路径等之前，都不会成为官方包管理器。

注释

  • 对这份 GLEP 的早期批评是，它没有解决 eclass 和配置文件。就 eclass 而言，我的观点是上述规则就足够了，因为 eclass 仅在其在 ebuild 中的使用中起作用。如果包管理器能够有效地处理所有 ebuild，那么它也必须成功地处理 eclass。另一方面，这里甚至没有隐式地涉及配置文件。
  • 假设 ebuild 规范已成功完成，那么第一条规则应该将“官方包管理器支持的所有 ebuild”替换为“满足 ebuild 规范的所有 ebuild”。类似地，在第二条规则中，“由官方包管理器”应改为“由官方 ebuild 规范”。

向后兼容性

这几乎是全部要点，并且这里明确说明了。