添加新的 ebuild

Gentoo 仓库中（不）应该放置的内容

在编写新的 ebuild 之前，请检查 bugs.gentoo.org 以查看是否已经为该软件包编写了 ebuild，但尚未添加到 Gentoo 仓库。访问 bugs.gentoo.org，选择查询并选择高级搜索；作为产品，选择 Gentoo Linux，作为组件，选择 新软件包。在搜索框中输入 ebuild 的名称，并将状态和解决方法选择所有可能字段，然后提交查询。对于懒人，这里有一个 Bugzilla 高级搜索 链接。

Gentoo 仓库应该仅用于存储 .ebuild 文件，以及任何小型伴随文件，例如补丁或示例配置文件。这些文件的大小应该最多为 20 KiB，并且必须放置在 mycat/mypkg/files 目录中，可以从 ebuild 中引用为 ${FILESDIR}。

较大的补丁应该放置在 dev.gentoo.org 上的开发者空间，而不是树，以最大限度地减少仓库大小。非开发者（例如代理维护者）可以在他们自己的某个稳定位置托管补丁 - 这里没有安全问题，因为清单将在提交时记录补丁校验和。

仓库中的文件应该是未压缩的纯文本文件，即，没有二进制文件。这将允许版本控制系统合并更改并正确地告知开发者冲突。

请记住，您提交的软件包必须在提交为稳定版本时“开箱即用”地准备好供最终用户使用。确保您有一组良好的默认设置，这些设置将满足使用您的软件包的大多数系统和用户。如果您的软件包已损坏，并且您不确定如何让它正常工作，请检查其他一些已经完成了自己版本的软件包的发行版。您可以检查 Debian 或 Fedora 以获取一些示例。

提交到 git 时，所有开发者都应该使用 pkgdev commit 和 pkgdev push，而不是 git commit 来提交他们的 ebuild。在提交之前，请运行 pkgcheck scan --commits 以确保您没有遗漏任何东西。

初始架构关键字

添加新的 ebuild 时，您应该只包含您实际测试过 ebuild 的架构的 KEYWORDS，确认它按预期工作，并且 USE 标志在将要安装的生成的软件包中得到正确处理。如果可能的话，您还应该对实际的库或应用程序进行彻底测试，因为您将对您的架构的任何故障负责。始终应该执行最小的测试，例如检查应用程序是否在没有错误的情况下启动。

如果您正在添加用户提交的 ebuild，不要假设提交者已经在各种架构上进行了测试：通常，KEYWORDS 是跨软件包克隆的，或者从源软件包的文档中生成的，这并不意味着软件包确实在这些架构上工作。

files 目录

如前所述，在每个软件包子目录下都是一个 files/ 目录。您的软件包可能需要的任何补丁、配置文件或其他辅助文件都应该添加到此目录；任何大于 20KB 或更大的文件都应该去镜像，以减少我们的用户必须下载的（不必要）文件量。您可能想要考虑将自己创建的补丁命名为一个版本特定的名称，例如 mypkg-1.0-gentoo.patch，或者更简单地说，1.0-gentoo.patch。还要注意，gentoo 扩展告诉人们此补丁是由我们，Gentoo Linux 开发人员创建的，而不是从邮件列表或其他地方获取的。再次，您不应该压缩这些补丁。

考虑为放入 files/ 目录的每个文件添加前缀或后缀（例如 mypkg-1.0），以便每个 ebuild 上的每个版本的使用的文件可以彼此区分，以及以便不同修订版之间的更改是可见的。这通常是一个非常好的主意：)。如果您希望使用补丁名称表达更多含义，您可能想要使用不同的后缀。

如果您有很多文件应该进入 files/ 目录，请考虑创建子目录，例如 files/1.0/，并将相关文件放在相应的子目录中。如果您使用这种方法，则不需要在文件名称中添加版本信息，这通常更方便。