可接受的公式
某些公式不应放入 homebrew/core 中。但还有其他 有趣的 Tap 和 Fork，任何人都可以 启动自己的 Tap！
homebrew/core 的要求
支持的平台
该公式需要在最新 3 个受支持的 macOS 版本（x86_64 和 Apple Silicon/ARM）以及 x86_64 Linux 上构建并通过测试。请查看 homebrew/core 中的拉取请求上的持续集成作业，以查看操作系统完整列表。如果上游不支持其中一个平台，则可以例外处理，并且可以为该平台禁用该公式。
系统包的重复项
我们现在接受随 macOS 提供的内容，只要它使用 keg_only :provided_by_macos 默认情况下为 keg-only 即可。
已版本化的公式
我们现在接受已版本化的公式，只要它们 满足要求。
通常不是 fork
除非满足以下至少一项条件，否则我们不会添加使用 fork 的新公式
- fork 已在原始源代码存储库（例如在 README 中）或由原始作者以公开可验证的方式（例如在问题或拉取请求评论中）指定为官方继任者
- fork 已被至少两个其他主要发行版（例如 Debian、Fedora、Arch、Gentoo，而不是未被广泛使用的较小 Linux 发行版）用作替代品
fork 仍必须满足所有其他可接受的公式要求（包括流行度和自提交等要求）。
替代 fork 替换原始公式的是新公式。例如，如果 MikeMcQuaid fork 了 curl 并且它非常流行：curl-mikemcquaid 公式可能是有意义的。
我们不喜欢会自行升级的工具
可以自行升级的软件与 Homebrew 公式本身的升级功能集成得不好。应禁用自动更新功能（同时最大程度地减少公式的复杂性）。对于 Cask，这是可以的（并且受到很好的支持）。
我们不喜欢下载未版本化内容的安装脚本
我们不喜欢从 Git 存储库的主分支或未版本化、未校验和的 tarball 中提取的安装脚本。理想情况下，这些脚本应使用 resource 块，其中包含特定修订版或校验和 tarball。请注意，我们现在允许 cargo、gem 和 pip 等工具在安装期间下载版本化库。当我们可以调用语言包管理器时，无需使用 resource 块来复制其功能。
我们不喜欢二进制公式
我们的政策是核心 tap (homebrew/core) 中的公式必须是开源的，并具有 Debian 自由软件准则许可证，并且是从源代码构建的或生成跨平台二进制文件（例如 Java、Mono）。仅二进制的公式应放入 homebrew/cask。
此外，核心公式也不得依赖于 cask 或任何其他专有软件。这包括在运行时自动安装 cask。
稳定版本
核心存储库中的公式必须具有上游项目标记的稳定版本。Tarball 优于 Git 检出，并且 tarball 应尽可能在文件名中包含版本。
我们不接受没有标记版本的软件，因为它们会因上游更改而定期中断，并且我们无法为它们提供 瓶子。
利基（或自提交）内容
有问题的软件必须
- 得到维护（即上次发布不是很久以前，它可以在所有 Homebrew 支持的操作系统版本上无需修补程序即可运行，并且没有未解决的未修补安全漏洞）
- 是稳定的（例如，上游未声明为“不稳定”或“测试版”）
- 是已知的（例如，GitHub 存储库应具有 >=30 个分支、>=30 个观察者或 >=75 个星标）
- 被使用
- 有一个主页
我们会拒绝看起来过于晦涩的公式，部分原因是它们不会得到维护，部分原因是我们必须在某个地方划清界限。
我们不赞成作者提交自己的作品，除非它非常流行。
别忘了 Homebrew 底层都是 Git！如果你必须的话，维护你自己的 tap！
主存储库中可能存在这些规则的例外情况；我们可能会包含不符合这些条件的内容或拒绝符合这些条件的内容。请相信，我们需要根据我们运营包管理器的经验来酌情处理。
构建 .app 的内容
不要让你的公式生成 .app（原生 macOS 应用程序）；我们不希望在 Homebrew 中看到这些东西。鼓励上游项目生成并支持 .app，该应用程序可由 homebrew/cask 分发（也可以不用它）。
默认构建 GUI 的内容（但不是必须的）
默认情况下，使其生成命令行工具或库，如果 GUI 有用且会被广泛使用，也生成 GUI。不要生成 X11/XQuartz GUI，因为它们在 macOS 上的用户体验很差。
无法使用最新稳定版 Xcode Clang 构建的内容
Clang 是 macOS 上的默认 C/C++ 编译器（并且已经很长时间了）。无法使用它生成的软件尚未充分移植到 macOS。
需要大量手动预/后安装干预的内容
我们是一个包管理器，因此我们希望为用户执行解析依赖项和设置应用程序等操作。如果某些操作需要过多的人工干预，那么它们在包管理器中就没有用。
共享库与静态库
一般来说，如果公式必须提供共享库或静态库：它们应该提供共享库。如果对静态库感兴趣，它们可以同时提供。应尽可能避免仅提供静态库，特别是当公式依赖于其他公式时，因为这些依赖项无法在不重新生成的情况下进行更新。
需要 Homebrew 公式的供应商版本的内容
Homebrew 公式应避免将多个独立的上游项目捆绑在一个包中，以避免提供已经成为公式的软件的过时/不安全的版本。Veracode 的 软件安全状况报告 得出结论
事实上，79% 的情况下，开发人员在将第三方库包含在代码库中后从未更新过它们。
有关详细信息，请参阅 Debian 和 Fedora 对此的立场。
不过，这种情况越来越多地变得（过于）困难。Homebrew 的主要使命是实用，而不是意识形态上的纯洁。如果我们无法在不使用供应商的上游版本的情况下打包某些内容：那就这样吧；在 Homebrew 中打包软件总比不打包好。
有时会有例外
即使满足所有条件，我们也可能不接受该公式。即使不满足某些条件，我们也可能接受该公式。新公式的标准高于现有公式。文档将落后于当前的决策制定。虽然某些拒绝可能看起来武断或奇怪，但它们是基于多年经验，使 Homebrew 能够为我们的用户提供可接受的工作。
