SolutionProcess

Процесс создания решений на базе Sisyphus

В этом цикле статей проводится попытка рассмотреть вопросы о вариантах использования Сизифа как метарешения для построения собственных решений. Делается оценка эффективности различных методов использования репозитория - их достоинства и недостатки.

Введение

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

• пакетный дистрибутив на основе среза Сизифа, с последующей стабилизацией пакетной базы
  • полный срез всей пакетной базы Сизифа - основа построения дистрибутивов ALT Linux в виде стабильной ветки
  • частичный срез Сизифа или стабильной ветки с дополнительными изменениями для решений конкретной задачи
• загрузочный образ или LiveCD
• предустановленная сборка в виде дерева каталогов, формируемого на основе пакетной базы Сизифа или стабильной ветки

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

Процесс разработки пакетных дистрибутивов

Создание дистрибутива

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

Итогом первоначально разработанного и воспроизводимого решения является устанавливаемый образ дистрибутива. Методов его установки может быть достаточно много. В том или ином виде методы установки бывают локальными (с какого-либо носителя, например CD или DVD) и сетевыми (например PXE плюс HTTP или NFS), а также могут быть автоматическими как в локальном, сетевом вариантах.

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

Создание веток

В случае создания пакетного дистрибутива на основе Сизифа ветки создаются и тестируются путём первоначального копирования самого Сизифа. Но ветка дистрибутива, как и сам Сизиф, не стоит не месте - она развивается. Стандартная схема разработки веток дистрибутивов АLT Linux приведена ниже:

Эта схема соответствует основному подходу к формированию веток на основе Сизифа для дистрибутивов ALTLinux. Процесс стабилизации пакетной базы Сизифа делится на этапы, по завершению которых производится выпуск стабильной ветки (например, текущая ветка 4.0, а следующая ветка 4.1).

С переходом основного числа разработчиков на Git появилась возможность в том или ином виде отслеживать процесс разработки пакетов в системе контроля версий. К сожалению, на текущий момент, для пакетов в стабильных ветках такие изменения для большинства пакетов не отслеживаются. Это приводит к тому, что любая стабильная постепенно становится не отслеживаемой в Git. Что, в свою очередь, приводит к невозможности вести историю ответвившегося репозитория. Таким образом текущая схема включает в себя ведение истории только для репозитория разработчиков. Любой срез организованный с целью стабилизации пакетной базы является своего рода произведением искусства и для его поддержания должны привлекаться отдельные усилия. Обычно эти усилия не планируются всеми участниками процесса разработки.

В этом плане есть можно привести следующее представление об итоговом репозитории. С одной стороны это src.rpm-пакеты, полученные из Git, или как нибудь иным путём попавшие в репозиторий (например, традиционно через rsync по ssh), и бинарные пакеты собранные из них. С другой стороны это всё те же исходники представленные в виде пакетной базы исходных пакетов, для которых существует бинарная пакетная база. Бинарные пакеты в этой базе представлены, как результат полученный из соответствующих исходных пакетов, в контексте всего набора пакетной базы исходных пакетов. В связи с этим пакеты собранные из одного и того же исходного пакета на разных бинарных пакетных базах могут не совпадать. И чем больше расходятся ветка и репозиторий разработчиков, тем больше вероятность расхождения результатов сборок одного и того же исходного пакета на их бинарных пакетных базах. То есть из одного и того же исходного пакета, собранного на разных бинарных репозиториях, строго говоря получаются разные бинарные пакеты. Поэтому, к сожалению, отслеживать этот процесс на уровне Git не представляется возможным.

Путей решения вопросов о поддержке в этом случае два подхода. Первый предполагает длительное время жизни ветки. В этом случае необходимо вести отдельный цикл разработки для каждой ветки в отдельности и сохранять их историю. Этого подхода придерживается большинство дистрибутивов. Второй подход предполагает, что все улучшения сначала вносятся в репозиторий разработчиков, а после этого, если требуется внести это улучшение в какую-либо ветку, то пакет переносится и пересобирается на бинарной пакетной базе этой ветки. В ALT Linux, по мнению автора, в основном принят такой подход. Причём при переносе пакетов в бранч (то есть в ветку), есть ряд правил смены релиза. Они существуют для того, чтобы при обновлении из Сизифа этот пакет был младше, соответствующего пакета в самом Сизифе.

Поддержка и обновление веток

Целью создания ветки является уход от быстро сменяющегося калейдоскопа версий библиотек, системообразующих утилит и приложений. Но поддержка, даже для стабилизированной пакетной базы всё равно требуется - находятся уязвимости, выходят новые версии важных приложений, которые нужно собрать на стабилизированной пакетной базе. Но бранч и Сизиф со временем существенно расходятся по версиям библиотек. В связи с этим возникает необходимость ведения так называемых бекпортов - репозиториев новых пакетов собранных для старых веток дистрибутивов. Кроме того в решениях на основе Сизифа, до последнего времени, в отличие, например от Ubuntu, не принято сохранять старые версии всех разделяемых библиотек (то есть сохранять так называемые sonames или "сонеймы"). Это означает, что для запуска старых сборок приложений на новом наборе библиотек требуется пересборка этих приложений на новых библиотеках. И если с бекпортами шла речь об обратной совместимости, то в случае с отсутствием старых библиотек, речь идёт о прямой.

Хотелось бы отметить очень важный момент относительно проблем обновления в России в настоящее время. Довольно большой проблемой является отсутствие общепринятых правил публикации обновлений и дополнительных приложений для дистрибутивов, собранных на основе стабильных веток. С учётом того, что юридические лица оплачивают интернет по трафику, получение обновлений и дополнительного ПО через интернет вызывает значительные дополнительные расходы. Это приводит к необходимости разворачивания локальных срезов стабильных репозиториев (в городах, сетях провайдеров, домовых сетях, локальной сети организации). Кроме того, доступная полоса пропускания интернет-каналов, в ряде случаев, сильно ограничена, что особенно ярко проявляется у региональных провайдеров.

Поддержка сторонних репозиториев

Для пакетных дистрибутивов существует три основных пути расширения пакетной базы сторонними разработками - участие в разработке Сизифа, создание альтернативных веток и расширение пакетной базы основных веток дополнительными репозиториями сторонних разработчиков. Рассмотрим их далее на примере варианта разработки дистрибутива компанией Etersoft.

Участие в разработке Сизифа

Участие в разработке Сизифа - это прямой путь для использования Сизифа, как площадке для создания и внедрения собственных решений. Но, при всей либеральности подхода к разработке Сизифа, для включения существенных поправок в отдельные пакеты требуется время. А кроме того необходимость согласования с различными разработчиками, которые имеют исключительное право на вопросы связанные с поддержкой своих пакетов, на что, как минимум, требуется ещё большее время. Участие в разработке Сизифа идеально подходит для создания решений, на основе тех пакетов, которые уже существуют и развиваются, но может стать невероятно сложным при желании быстро сменить важные элементы системы, поскольку на них могут быть завязаны остальные участники.

Создание альтернативных веток

Необходимость существенно обновить пакетную базу вышедшего дистрибутива на основе стабильной ветки или желание собрать собственный дистрибутив, в ряде случаев, приводит к необходимости создания собственной стабильной ветки. Это накладывает дополнительные расходы на её поддержание и обновление, но позволяет полностью решить вопросы связанные проблемами синхронизации и поддержания в актуальном состоянии своих изменений пересекающейся с пакетной базой используемой стабильной ветки. Создание альтернативной ветки производится на основе текущей стабильной или, что более принято, на основе Сизифа. Схема разработки дистрибутивов на основе Сизифа, путём организации альтернативной ветки, приведена ниже:

http://ftp.etersoft.ru/download/git/git-alt-etersoft.png

Расширение пакетной базы основных веток

Создание конкретных, фиксированных решений, которые обычно принято называть программными продуктами, в Linux мало распространено. Это связано с тем, что свободное программное обеспечение может собрано в рамках репозитория разработчиков. Тем не менее необходимость расширения пакетной базы стабильных веток существует. Прежде всего это позволяет избежать дублирования действий по стабилизации пакетной базы, а также позволяет вести гарантированно совместную работу в рамках общего набора базовых пакетов, которые никуда не разбегутся со временем. К сожалению, сложности синхронизации, пересечение по функциональным возможностям необходимых пакетов, необходимость согласованного обновления приложений и библиотек вынуждают создавать альтернативные ветки. Тем не менее, если базовое решение стабильно и удовлетворяет необходимой функциональности - это один из самых интересных подходов. Как с точки зрения пользователей, так и с точки зрения разработчиков. Схема разработки этого варианта представлена ниже:

http://ftp.etersoft.ru/download/git/git-alt-etersoft-together.png