Опыт поддержки догоняющей сборки «Сизифа» (Иван Мельников, OSSDEVCONF-2023)

Ссылки сюда (1) →

Короткая ссылка: 20230930H

Докладчик

Иван Мельников

«Сизиф» как репозиторий свободного ПО поддерживает несколько аппаратных архитектур, часть из которых являются основными и обновляются синхронно, а часть догоняющими (не блокируют сборку на основные архитектуры).

В докладе рассмотрены технические и философские особенности организации сборки на такие догоняющие архитектуры.

Презентация

Thesis

«Сизиф» как репозиторий свободного ПО поддерживает несколько аппаратных архитектур. Каждое изменение репозитория оформляется в виде задания (task), в которое могут входить сборка или удаление одного или нескольких пакетов. Такие задания исполняются сразу для нескольких архитектур, и изменения в репозитории для этих архитектур происходят синхронно. Такие архитектуры мы называем основными.

Помимо основных архитектур, существуют порты «Сизифа» на другие архитектуры, среди которых mipsel (MIPS32 little endian, o32 ABI), riscv64 (RV64GC, lp64d ABI), «Эльбрусы», а также недавно созданный ООО «Базальт СПО» новый порт на архитектуру loongarch64 (new world).

Автор несколько лет поддерживает порты «Сизифа» на mipsel и riscv64. Именно о них пойдёт речь в этом докладе.

Инфраструктура сборки пакетов для mipsel и riscv64 аналогична используемой для основных архитектур: используется отдельный экземпляр girar и отдельный репозиторий (включая собственный компонент noarch). После того, как задание для основного «Сизифа» успешно завершено, специальный робот создаёт аналогичное задание в «догоняющий» girar. После одобрения мейнтенером порта задания собираются.

Существует несколько факторов, которые могут не позволять порту стать основной архитектурой. Не претендуя на полноту, отмечу некоторые из них.

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

Готовность репозитория. В догоняющие репозитории обычно собрано меньше пакетов, чем в основной «Сизиф». Даже пакеты, казалось бы, не требующие портирования, часто требуют адаптации для сборке на ещё одной архитектуре. Также в «Сизифе» распространены циклы из сборочных зависимостей, которые при первой сборке таких пакетов на новую архитектуру приходится вручную разрывать. Поэтому развитие порта — это достаточно долгая работа. При этом репозиторий становится полезным задолго до её завершения — например, можно выпускать полезные образы ОС, имея в репозитории 3—4 тысячи пакетов из собранных в «Сизиф» примерно 18 тысяч (имеются ввиду source-пакеты).

Поддержка сторонних патчей. При сборке на сравнительно новую и/или малопопулярную архитектуру часто приходится вносить в код какие-либо изменения. Эти изменения нужно поддерживать при выходе новых версий. Не всегда возможно и не всегда правильно перекладывать эту работу на мейнтейнера пакета в основном «Сизифе»; также не всегда удаётся передать изменения разработчикам. Мейнтейнер «догоняющего» порта в такой ситуации может поддерживать свой «мини-форк», что в основном «Сизифе» было бы организационно сложнее.

Хочется также отметить несколько особенностей, к которым приводит «догоняющая» сборка пакетов.

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

Возникает соблазн и возможность «придержать» некоторые обновления, особенно те, про которые точно известно, что они ломают сборку многих пакетов. Это оправдано на раннем этапе развития порта, когда в приоритете расширение пакетного состава репозитория. Тогда приходится особенно много собирать пакетов, которые в основной «Сизиф» были собраны значительно раньше, в других условиях.

Стоит отметить, что и достаточно зрелые порты продолжают развиваться. Например, в этом году порт riscv64 вырос более чем на 1300 source-пакетов. Это означает, что задача собрать пакет, собранный в «Сизиф» когда-то давно, типична для мейнтейнера порта, и на исправление сборки пакетов в основном «Сизифе» уходит достаточно много сил и времени.

Однако в целом имеет смысл стараться сводить отличия от основного «Сизифа» к минимуму. Во-первых, потому что концептуально порт — это не форк; во-вторых, потому, что решать проблемы, которые затрагивают и основной «Сизиф», помогая тем самым всему сообществу, важнее и интереснее, чем бороться со специфичными проблемами, вызванными отличиями от основного репозитория.