В этом цикле статей проводится попытка рассмотреть вопросы о вариантах использования Сизифа как метарешения для посторения собственных решений. Делается оценка эффективности различных методов использования репозитория – их достоинства и недостатки.
Дистрибутивом на основе пакетного репозитория можно назвать целую плеяду решений. Варианты решений обычно привязаны к особенностям реализации и сфере их применения. По сферам применения решния можно разделить на десктопные, серверные и специализированные. В число основных вариантов можно включить следующие:
Все эти решения имеют в качестве основы набор средств для автоматизированной сборки. Ранее это был Separator?, теперь это Mkimage. Предварительно это почти весь набор необходимых средств для создания своего дистрибутива.
Но дистрибутив, как и сам Сизиф, не стоит не месте – он развивается. Стандартная схема разработки дистрибутивов АLT Linux приведена ниже:
Эта схема соответствует основному подходу к формированию веток на основе Сизифа для дистрибутивов ALTLinux. Процесс стабилизации пакетной базы Сизифа делится на этапы, по завершению которых производится выпуск стабильной ветки (например, текущая ветка 4.0, а следующая ветка 4.1).
С переходом основного числа разработчиков на Git появилась возможность в том или ином виде отслеживать процесс разработки пакетов в системе контроля версий. К сожалению, на текущий момент, для пакетов в стабильных ветках такие изменения для большинства пакетов не отслеживаются. Это приводит к тому, что любая стабильная постепенно становится не отслеживаемой в Git. Что, в свою очередь, приводит к невозможности вести историю ответвившегося репозитория. Таким образом текущая схема включает в себя ведение истории только для репозитория разработчиков. Любой срез организованный с целью стабилизации пакетной базы является своего рода произведением искусства и для его поддержания должны привлекаться отдельные усилия. Обычно эти усилия не планируются всеми участниками процесса разработки.
В этом плане есть можно привести следующее представление об итоговом репозитории. С одной стороны это src.rpm-пакеты, полученные из Git, или как нибудь иным путём попавшие в репозиторий (например, традиционно через rsync по ssh), и бинарные пакеты собранные из них. С другой стороны это всё те же исходники представленные в виде пакетной базы исходных пакетов, для которых существует бинарная пакетная база. Бинарные пакеты в этой базе представлены, как результат полученный из соответствующих исходных пакетов, в контексте всего набора пакетной базы исходных пакетов. В связи с этим пакеты собранные из одного и того же исходного пакета на разных бинарных пакетных базах могут не совпадать. И чем больше расходятся ветка и репозиторий разработчиков, тем больше вероятность расхождения результатов сборок одного и того же исходного пакета на их бинарных пакетных базах. Отслеживать этот процесс на уровне Git не представляется возможным.
Путей решения вопросов о поддержке в этом случае два подхода. Первый предполагает длительное время жизни ветки. В этом случае необходимо вести отдельный цикл разработки для каждой ветки в отдельности и сохранять их историю. Этого подхода придерживается большинство дистрибутивов. Второй подход предполагает, что все улучшения сначала вносятся в репозиторий разработчиков, а после этого, если требуется внести это улучшение в какую-либо ветку, то пакет переносится и пересобирается на бинарной пакетной базе этой ветки. В ALT Linux, по мнению автора, в основном принят такой подход. Причём при переносе пакетов в бранч (то есть в ветку), есть ряд правил смены релиза. Они существуют для того, чтобы при обновлении из Сизифа этот пакет был младше, соответствующего пакета в самом Сизифе.
Целью создания ветки является уход от быстро сменяющегося калейдоскопа версий библиотек, системообразующих утилит и приложений. Но поддержка, даже для стабилизированной пакетной базы всё равно требуется – находятся уязвимости, выходят новые версии важных приложений, которые нужно собрать на стабилизированной пакетной базе. Но бранч и Сизиф со временем существенно расходятся по версиям библиотек. В связи с этим возникает необходимость ведения так называемых бекпортов – репозиториев новых пакетов собранных для старых веток дистрибутивов. Кроме того в решениях на основе Сизифа, до последнего времени, в отличие, например от Ubuntu, не принято сохранять старые версии всех разделяемых библиотек (то есть сохранять так называемые sonames или «сонеймы»). Это означает, что для запуска старых сборок приложений на новом наборе библиотек требуется пересборка этих приложений на новых библиотеках. И если с бекпортами шла речь об обратной совместимости, то в случае с отсутствием старых библиотек, речь идёт о прямой.
Хотелось бы отметить, очень важный момент относительно проблем обновления в России в настоящее время. Довольно большой проблемой является отсутствие общепринятых правил публикации обновлений и дополнительных приложений для дистрибутивов, собранных на основе стабильных веток. С учётом того, что юридические лица оплачивают интернет по трафику возникают. Получение обновлений и дополнительного ПО исключительно, через интернет представляет собой значительные накладные расходы и необходимость разворачивания локальных срезов стабильных репозиториев. Кроме того, доступная полоса пропускания интернет каналов, в ряде случаев, сильно ограничена, что особенно ярко проявляется у региональных провайдеров.
Для пакетных дистрибутивов существует три основных пути расширения пакетной базы сторонними разработками – участие в разработке Сизифа, создание альтернативных веток и расширение пакетной базы основных веток дополнительными репозиториями сторонних разработчиков. Рассмотрим их далее на примере варианта разработки дистрибутива компанией 
Etersoft.
Участие в разработке Сизифа – это прямой путь для использования Сизифа, как площадке для создания и внедрения собственных решений. Но, при всей либеральности подхода к разработке Сизифа, для включения существенных поправок в отдельные пакеты требуется время. А кроме того необходимость согласования с различными разработчиками, которые имеют исключительное право на вопросы связанные с поддержкой своих пакетов, на что, как минимум, требуется ещё большее время. Участие в разработке Сизифа идеально подходит для создания решений, на основе тех пакетов, которые уже существуют и развиваются, но может стать невероятно сложным при желании быстро сменить важные элементы системы, поскольку на них могут быть завязаны остальные участники.
Необходимость существенно обновить пакетную базу вышедшего дистрибутива на основе стабильной ветки или желание собрать собственный дистрибутив, в ряде случаев, приводит к необходимости создания собственной стабильной ветки. Это накладывает дополнительные расходы на её поддержание и обновление, но позволяет полностью решить вопросы связанные проблемами синхронизации и поддержания в актуальном состоянии своих изменений пересекающейся с пакетной базой используемой стабильной ветки. Создание альтернативной ветки производится на основе текущей стабильной или, что более принято, на основе Сизифа. Схема разработки дистрибутивов на основе Сизифа, путём организации альтернативной ветки, приведена ниже:
Powered by WackoWiki R4.2