---
title: "Проблемы реализации, связанные с Коллекцией портов"
sidenav: about
---

//
// The FreeBSD Russian Documentation Project
//
// Original EN revision (21.02.2021): eb4b89b8d31574df0a18fc5f7562181ccd6eecd6
//

= Проблемы реализации, связанные с Коллекцией портов

== Дерево портов не ветвится

В отличие от дерева `src`, дерево портов FreeBSD *не* ветвится. Всегда считалось, что у нас слишком мало добровольцев, чтобы справляться с работой по слиянию сотен изменений из последнего дерева в различные ветки.

== Практические соображения

Существуют тысячи, если не десятки тысяч, пользовательских установок, которые отслеживают дерево портов ежедневно, вместо того чтобы полагаться на пакеты, поставляемые с последним выпуском FreeBSD. Соответственно, любая критическая ошибка в инфраструктуре портов немедленно затронет все эти сайты. Именно поэтому коммиты в `bsd.port.mk` разрешены только с одобрения portmgr. За исключением необычных случаев, это одобрение предоставляется только после проведения регрессионного теста в выделенной области автоматизированного http://pointyhat.FreeBSD.org[кластера сборки портов]. Обычно одновременно тестируется дюжина или более предлагаемых изменений инфраструктуры, и portmgr вносит изменения только после успешной сборки всего дерева портов.

[[requires_regression_test]]
== Изменения, требующие регрессионных тестов

Изменения в `bsd.port.mk` — не единственные коммиты, которые могут кардинально повлиять на дерево. Мы просим, чтобы любые подобные изменения также тестировались на кластере. Примеры таких изменений, которые следует тестировать перед коммитом, включают:

* изменения в пакетах с множеством зависимостей, включая X11 серверы, GNOME, KDE, gettext, autotools и т.д.
* изменения, меняющие «общепринятую лучшую практику» для Makefile-файлов портов, такие как определения или использование общих переменных make (или `Makevar`). (например, объединение различных реализаций USE_*, WITH_* и т.д.)
* крупные repocopy (например, когда существующая категория портов разделяется)

Если вы не уверены, потребует ли ваше предлагаемое изменение регрессионного теста, пожалуйста, отправьте электронное письмо на portmgr@FreeBSD.org.

== Влияние на цикл выпуска

Когда предстоит новый выпуск FreeBSD, коммиттеров просят сместить акцент с добавления новых портов и функций на исправление существующих проблем. В определенный момент во время выпуска дерево `tagged` (помечается тегом), и из каждого порта создаются пакеты для каждой из архитектур. Из-за большого количества портов и скорости более медленных архитектур процесс сборки занимает несколько дней.

В идеальном мире именно эти пакеты попадали бы на CD выпуска, а время от создания пакетов до фактического выпуска было бы достаточно лишь для их тестирования и не более. Однако на практике в ходе усилий по обеспечению качества (QA) обнаруживаются проблемы как в портах, так и в дереве исходного кода. Но чтобы иметь возможность выпустить систему своевременно, в фактическое (помеченное тегом) дерево будут влиты только определенные изменения портов, и затронутые пакеты будут собраны заново. Только для серьезных проблем безопасности и проблем с лицензированием теги будут изменены таким образом.

Поскольку период выпуска может занимать недели, нереалистично не разрешать никакие коммиты в дерево портов в это время. Проблема с разрешением неограниченных коммитов в это время заключается в том, что становится невозможно выделить только критические изменения, чтобы только они (и только они) могли привести к изменению своих тегов. Термин для изменений, которые не разрешены, — `sweeping changes` (масштабные изменения).

[[sweeping_changes]]
== Что такое масштабное изменение?

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

Вот неполный список. Если вы не уверены, попадает ли ваше предлагаемое изменение в эту категорию, вы *должны* спросить portmgr перед коммитом.

* любой коммит в `bsd.*.mk`
* все остальное, что обычно требует link:#requires_regression_test[регрессионного теста]
* увеличение версии разделяемых библиотек (shared library version bumps)
* repocopy, затрагивающие несколько портов

Следующее *не* попадает в указанную выше категорию:

* коммиты в листовые порты (т.е. порты, от которых не зависят другие порты)
* косметические изменения, которые не влияют на пакет (например, изменения в `pkg_descr`)
* новые порты
* repocopy отдельных портов

Подводя итог: основной вопрос — *повлияет ли это изменение на другие пакеты?*.
