Допустимые формулы

Некоторые формулы не должны попадать в homebrew/core. Но есть и другие интересные tap-репозитории и форки, и каждый может создать свой!

Если вы разработчик или представитель upstream-проекта и хотите узнать больше о том, как Homebrew работает с upstream-проектами, прочитайте также Работа с Homebrew в качестве upstream-проекта.

Требования к homebrew/core
Иногда бывают исключения

Требования к `homebrew/core`

Поддерживаемые платформы

Формула должна собираться и проходить тесты на трёх последних поддерживаемых версиях macOS (Apple Silicon и x86_64), а также на Linux для x86_64. Чтобы увидеть полный список ОС, ознакомьтесь с заданиями непрерывной интеграции для pull request в homebrew/core. Если upstream-проект не поддерживает одну из этих платформ, можно сделать исключение и отключить формулу для этой платформы.

Дубликаты системных пакетов

Теперь мы принимаем программы, входящие в состав macOS, если для них используется keg_only :provided_by_macos, чтобы по умолчанию они устанавливались только в keg.

Версионируемые формулы

Теперь мы принимаем версионируемые формулы, если они соответствуют требованиям.

Не форк (обычно)

Мы не будем добавлять новые формулы на основе форков, если не выполняется хотя бы одно из следующих условий:

форк объявлен официальным преемником в исходном репозитории (например, в README) или первоначальным автором способом, который можно публично проверить (например, в комментарии к issue или pull request)
форк используется в качестве замены как минимум двумя другими крупными дистрибутивами (например, Debian, Fedora, Arch или Gentoo, но не небольшими, малоиспользуемыми дистрибутивами Linux)

Форк по-прежнему должен соответствовать всем остальным требованиям к допустимым формулам (в том числе требованиям к популярности и самостоятельному предложению).

Вместо замены исходной формулы форком можно добавить новую формулу. Например, если MikeMcQuaid создал форк curl, и тот стал очень популярным, может иметь смысл добавить формулу curl-mikemcquaid.

Нам не нравятся инструменты, которые обновляются самостоятельно

Программы с функцией самостоятельного обновления плохо сочетаются со встроенной в формулы Homebrew функцией обновления. Функцию самостоятельного обновления следует отключить (не усложняя при этом формулу). Для Cask это допустимо и хорошо поддерживается.

Нам не нравятся скрипты установки, загружающие неверсированные файлы

Нам не нравятся скрипты установки, которые загружают файлы из ветки по умолчанию Git-репозиториев или неверсированные tar-архивы без контрольной суммы. В идеале для этого следует использовать блоки resource с конкретными ревизиями или tar-архивы с контрольными суммами. Обратите внимание: теперь мы разрешаем таким инструментам, как cargo, gem и pip, загружать версионируемые библиотеки во время установки. Нет необходимости воспроизводить возможности менеджера пакетов какого-либо языка с помощью блоков resource, если вместо этого можно вызвать сам менеджер.

Нам не нравятся бинарные формулы

Согласно нашей политике, формулы в основном tap-репозитории (homebrew/core) должны быть программами с открытым исходным кодом, распространяемыми по лицензии, соответствующей Руководству Debian по свободному ПО, и либо собираться из исходного кода, либо создавать кроссплатформенные бинарные файлы (например, Java, Mono). Формулы, распространяемые только в бинарном виде, следует помещать в homebrew/cask.

Кроме того, формулы core не должны зависеть от cask или другого проприетарного программного обеспечения. Это включает автоматическую установку cask во время выполнения.

Стабильные версии

Формулы в основном репозитории должны иметь стабильную версию, помеченную upstream-проектом. Предпочтительны tar-архивы, а не Git checkout; по возможности имя tar-архива должно содержать номер версии.

Мы не принимаем программы без версии, отмеченной тегом: они регулярно перестают работать из-за изменений в upstream-проекте, и для них нельзя предоставлять готовые сборки.

Узкоспециализированные проекты (или предложенные авторами)

Рассматриваемая программа должна:

быть стабильной (например, upstream-проект не должен объявлять её «нестабильной» или «бета-версией»)
поддерживаться (то есть новая формула должна соответствовать стабильному выпуску, работать без патчей во всех версиях ОС, поддерживаемых Homebrew, и не иметь известных неисправленных уязвимостей безопасности)
быть известной (например, у GitHub-репозитория должно быть >=30 форков, >=30 наблюдателей или >=75 звёзд)
- для ПО, предложенного его авторами, требования к известности в 3 раза выше указанных пороговых значений (например, на GitHub: >=90 форков, >=90 наблюдателей или >=225 звёзд)
использоваться кем-либо помимо автора (например, pull request отправил не автор либо кто-то открыл issue у нас или у авторов с просьбой добавить программу в Homebrew)
иметь главную страницу (например, сайт в интернете; это может быть GitHub-репозиторий с README, который можно открыть в браузере и узнать о проекте)

Не забывайте, что в основе Homebrew лежит Git! Если нужно, поддерживайте собственный tap-репозиторий!

В основном репозитории возможны исключения из этих правил: мы можем включить программы, которые не соответствуют этим критериям, или отклонить те, которые им соответствуют. Пожалуйста, доверьтесь нашему усмотрению, основанному на опыте сопровождения менеджера пакетов.

Проекты, собирающие `.app`

Не создавайте формулу, которая собирает .app (нативное приложение macOS): мы не хотим добавлять такие программы в Homebrew. Предложите upstream-проекту собирать и поддерживать .app, которое можно распространять через homebrew/cask (и использовать без него).

Проекты, которые по умолчанию собирают графический интерфейс (хотя это необязательно)

По умолчанию собирайте инструмент командной строки или библиотеку, а если графический интерфейс полезен и будет широко использоваться, собирайте также и его. Не собирайте графические интерфейсы для X11/XQuartz: в macOS они неудобны для пользователей.

Проекты, которые не собираются последней стабильной версией Clang из Xcode

Clang уже давно является компилятором C/C++ по умолчанию в macOS. Программы, которые с ним не собираются, недостаточно хорошо адаптированы для macOS.

Проекты, требующие значительных ручных действий до или после установки

Мы — менеджер пакетов, поэтому хотим выполнять такие задачи, как разрешение зависимостей и настройка приложений для пользователей. Если программа требует слишком много ручных действий, она не подходит для менеджера пакетов.

Динамические и статические библиотеки

Как правило, если формула должна включать динамические или статические библиотеки, следует включать динамические. При наличии спроса на статические библиотеки можно включить оба типа. По возможности не следует включать только статические библиотеки — особенно если от формулы зависят другие формулы, поскольку эти зависимости нельзя обновить без повторной сборки.

Проекты, которым требуются встроенные версии формул Homebrew

Формулам Homebrew следует избегать объединения нескольких отдельных upstream-проектов в одном пакете, чтобы не поставлять устаревшие или небезопасные версии программ, для которых уже есть формулы. В отчёте Veracode о состоянии безопасности программного обеспечения говорится:

На самом деле в 79% случаев разработчики никогда не обновляют сторонние библиотеки после включения их в кодовую базу.

Подробнее см. позиции Debian и Fedora по этому вопросу.

Однако всё чаще это оказывается (слишком) сложно. Главная задача Homebrew — быть полезным, а не следовать идеологической чистоте. Если упаковать программу без использования встроенных upstream-версий невозможно, пусть будет так: лучше добавить программу в Homebrew, чем не добавлять её вовсе.

Контент для взрослых

Homebrew — это инструмент, которым пользуются преимущественно взрослые. У нас есть пользователи по всему миру, и их взгляды на секс, насилие и другие темы различаются. Поэтому мы не считаем, что должны навязывать пользователям взгляды какой-либо культуры на контент для взрослых. При этом мы хотим, чтобы сопровождающим не приходилось взаимодействовать с таким контентом, если они сами этого не хотят.

Мы принимаем формулы с контентом для взрослых, но требуем, чтобы homepage и корневая страница домена url были «безопасными для работы», то есть не отображали изображения насилия или контента для взрослых. На этих страницах допустимы текстовые описания контента для взрослых.

Homebrew оставляет за собой право добавлять или удалять формулы в зависимости от их влияния на экосистему Homebrew в целом. Например, если критически важный узел инфраструктуры потребует удалить формулу, чтобы поддерживать нашу инфраструктуру, мы можем неохотно удалить её ради непрерывной работы сервиса для пользователей.

Иногда бывают исключения

Даже если все критерии соблюдены, мы можем не принять формулу. И наоборот, мы можем принять формулу, которая не соответствует некоторым критериям. К новым формулам предъявляются более строгие требования, чем к существующим. Документация может отставать от текущей практики принятия решений. Хотя некоторые отказы могут показаться произвольными или странными, за ними стоит многолетний опыт обеспечения приемлемой работы Homebrew для наших пользователей.