Gentoo 仓库
Gentoo 仓库的基本布局如下
- 类别，例如
app-editors、sys-apps- 类别元数据，例如
app-admin/metadata.xml - 软件包目录，例如
app-editors/vim- 软件包元数据，例如
app-editors/vim/metadata.xml - 软件包清单，例如
app-editors/vim/Manifest - Ebuild 文件，例如
app-editors/vim/vim-6.3.068.ebuild、app-editors/vim/vim-7.0_alpha20050326.ebuild - 软件包文件目录，例如
app-editors/vim/files- 小型补丁和其他杂项文件，例如
app-editors/vim/files/vim-completion
- 小型补丁和其他杂项文件，例如
- 软件包元数据，例如
- 类别元数据，例如
- Eclass 目录，
eclass/ - 许可证目录，
licenses/ - 元数据目录，
metadata/。大多数列出的内容不会直接保存在主 Git 树中，而是作为 Git 到 Rsync 过程的一部分，从其他仓库自动生成或包含。- 各种控制文件，例如
layout.conf、timestamp和projects.xml。只有layout.conf存在于主 Git 树中。 - 位于
metadata/dtd/和metadata/xml-schema/中的 XML 验证文件。 - 位于
metadata/glsa/中的安全公告和位于metadata/news/中的新闻项目
- 各种控制文件，例如
- 配置文件目录，
profiles/- 各种控制和文档文件，例如
categories、info_pkgs、info_vars、package.mask、use.desc - 更新目录，
profiles/updates/- 更新文件，例如
profiles/updates/1Q-2005
- 更新文件，例如
- 主配置文件级联
- 各种控制和文档文件，例如
- 脚本目录，
scripts/
树中应该包含什么？
树中不应该包含的内容
- 大型补丁
- 非文本文件
- Teletubbies 的照片
- 文件名包含
[A-Za-z0-9._+-]以外字符的文件 - 文件名以点、连字符或加号开头的文件
发行版文件的命名规则更加宽松，但为了互操作性，其文件名仅限于可打印的 ASCII 范围，不包括空格，即 U+0021 到 U+007E（另请参阅 GLEP 31）。还应避免在 Bash 或 SRC_URI 中具有特殊含义的任何字符。如有必要，可以使用 -> 语法对上游文件进行 重命名。
从软件方面来说，一般来说，为了将软件包包含到树中，应满足以下所有条件
- 活跃、合作的上游
- 如果软件包在上游未开发或未维护，则修复问题可能极其困难。如果软件包没有活跃的上游，则将软件包添加到树中的开发人员必须确保他们能够解决可能出现的任何问题。
- 有时上游可能出于某种原因不希望将其软件包包含在树中。应尊重这一点。
- 相当稳定
- 不要将超级实验性的内容包含在树中。如果必须提交它们，请考虑使用
package.mask直到情况稳定下来，或者更好地将它们作为覆盖层 ebuild 提供。 - 相当有用
- 不要觉得有义务将“Joe 的 '1337 XMMS 皮肤合集”或“Hans 的超级酷炫快速文件系统”包含在树中，仅仅因为一些用户请求它。坚持那些可能真正有用的东西。
- 正确打包
- 如果某些内容仅在动态 CVS 或不可靠的自动打包格式中可用，请不要包含它，直到上游能够提供一个体面的源代码包。同样，避免那些没有正确构建系统（在相关的情况下）的东西——这些东西很难维护。
- 允许修补和分发
- 如果我们无法根据需要自行修补软件包，那么我们最终将完全依赖上游的支持。这可能有问题，尤其是在上游修复问题速度缓慢的情况下。我们不希望出现无法稳定关键软件包的情况，因为我们仍在等待闭源供应商采取行动。
- 同样，无法自行镜像和分发 tarball 会使我们完全依赖上游镜像。经验表明，这些镜像通常非常不可靠，文件会随机更改、移动或消失。
- 有效的 Ebuild
- 如果没有有效的 ebuild，请不要包含它。
- 可移植
- 如果软件不可移植，通常是因为编写不当。请记住，尽管 x86 现在拥有大部分市场份额，但在 x86-64 流行起来后，这种情况可能在不久的将来不会持续。
- 合理的安全记录
- 不要包含安全记录很差的软件。每个漏洞都会给很多人（安全团队、架构团队和软件包维护人员）带来大量的工作。