Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019)

Материал из 0x1.tv

(перенаправлено с «20190828K»)
Докладчик
Владимир Селезнев

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

Видео

on youtube

Презентация

Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019).pdf

Thesis

Пакеты

Пакеты делятся на два типа: исходные и бинарные. Исходные пакеты содержат в себе исходные тексты и материалы, патчи и дополнительные файлы и инструкции сборки их в бинарные пакеты. Бинарные пакеты как правило содержат уже откомпилированные программы, библиотеки и данные, и предназначены для установки на целевые системы. У каждого пакета есть уникальное имя, обычно включающее в себя апстримное[1] название проекта, версия (совпадает с версией исходного проекта) и релиз, обозначающий ревизию сборки данного проекта данной версии. Обычно релиз изменяют, когда надо произвести какие-то изменения в пакете этой же версии: исправить ошибку сборки или самого пакета, закрыть уязвимость и т.д.. Каждый пакет можно однозначно идентифицировать по этой твойке: %name-%version-%release[2].

Пакеты и бранчи

В процессе жизни бранча пакеты в нём могут обновляться сопровождающими пакетов или бранча, значение версии обновлённого пакета больше предыдущего (для простоты будем называть версией пакета связку {%epoch:}%version-%release, где %version имеет приоритет над %release, а %epoch над %version). В штатном режиме пакетный менеджер может обновлять пакеты на целевой системе, если кандидаты на обновления имеют более высокую версию, чем установленные.

Для решения задачи обновления установленной системы с одного бранча на более новый был введён запрет на сборку в нижелезащие бранчи пакетов с версией, большей чем в вышележащие, а для задачи бэкпортирования пакетов из вышестоящих бранчей был введён backport policy, который справлялся с ней, пока бранчей было немного, и они были линейно упорядочены.

Современные проблемы бранчей

Со временем количество бранчей увеличилось, а также исчез линейный порядок. Помимо этого также существовала потребность собирать пакеты из одних их тех же исходников в разные бранчи. Регулярно возникали случаи, когда необходимо было пересобрать пакет без фактического изменения исходников, что было невозможно ввиду требования уникальности %name-%epoch:%version-%release, однозначно определявшей сборку пакета, из-за чего приходилось увеличивать релиз. Различными участниками команды придумывались обходные пути для решения этих задач, которые плохо влияли на воспроизводимость сборки пакетов.

Строгие зависимости пакетов нового вида

Необходимо было решить задачу сборки бинарных пакетов в разные бранчи из одних и тех же исходных пакетов, а также пересборки пакетов без увеличения релиза. В качестве системного решения было предложено использовать более строгие зависимости пакетов с использованием build-id для различения бинарных сборок пакетов на основе хэшей от нефиктивной информации о пакетах в дополение к имени и версии пакета (через дополнительные предоставляемые и требуемые зависимости вида .hash-%name-%version-%release). Но от варианта с хэшом отказались из-за того, что он несовместим с возможностью сборок noarch- и arch-подпакетов из одного исходного пакета.

Вместо хэша было решено использовать информацию о целевом бранче и о сборочном задании, в котором собирется пакет. Эта информация для наглядности стала записываться в rpm тег disttag’ов. Предполагалось, что пакет будет предоставлять строгую зависимость вида .disttag-%name-%version-%release, как в схеме с хэшом, только со значением disttag’а на месте хэша. Но после её внедрения оказалось, что из-за особенностей алгоритма обработки apt’ом виртуальных пакетов начали возникать ошибки установки и обновления пакетов. Нужно было срочно переделывать схему на другую, лишённую такого недостатка.

В итоге выбор был сделан на зависимости, представляющие расширение традиционных для rpm-пакетов зависимостей вида

%name = {%epoch:}%version-%release

до

%name = {%epoch:}%version-%release:%disttag.

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

Conflicts: foo > %{EVR}

Conflicts: foo < %{EVR}

Решением всех проблем являлось обновление rpm на целевой системе.

Оставалось решить проблему обновления на новый бранч. Т.к. линейный порядок бранчей утрачен, решение о том, пакеты из какого бранча свежее, переложен на системного администратора. Рассматривались варианты с правкой apt_preferences и выставлением на нужный бранч высокого Pin-Priority, но особенности алгоритма вычисления весов в apt делали такой вариант не надёжным. В конце концов был введён новый макрос rpm %_priority_distbranch, значение которого обозначает наиболее приоритетный бранч для установки пакетов.

Бранчи и пакеты в Альте — от backport policy к disttag (Селезнев Владимир, OSSDEVCONF-2019)!.jpg

Примечания и ссылки

  1. Апстрим — команда или автор, предоставляющие оригинальные исходники
  2. Иногда перед версией может находиться эпоха пакета: суперверсия пакета

Plays:67   Comments:1