Binary package identity change
Версия от 02:56, 24 мая 2018; VladimirSeleznev (обсуждение | вклад)
Действующие правила именования релизов собранных пакетов
Правила нумерации релизов пакетов, собираемых в бранчи, изначально были введены для решения следующих задач:
- Обновляемость: каждый бинарный пакет из более старого бранча должен был обновляться до одноимённого пакета из более свежего бранча.
- Идентификация: набор NEVR каждого бинарного пакета должен был однозначно определять целевой бранч, в который этот пакет был собран, а также исходный пакет, из которого была выполнена сборка.
- Наглядность: имя целевого бранча каждого бинарного пакета должно было быть видно там, где виден номер релиза этого пакета.
Проблемы традиционного именования релизов собранных пакетов
Однако со временем число бранчей выросло, а их линейный (а порой даже частичный) порядок был утрачен. Сейчас ответ на вопрос, какой бранч свежее, уже фактически переложен на администратора системы. Для поддержки сборок из одних и тех же исходников в разные бранчи возникли конструкции вроде %ubt, отрицательно влияющие на воспроизводимость сборки. В то же время, копирование пакетов также регулярно приводит к проблемам как в пересобираемости, так и в работоспособности скопированного. Очевидно, что Backports_Policy устарел.
Предлагаемые изменения идентификации собранных пакетов
Предлагается изменить правила следующим образом:
- Правила нумерации релизов пакетов, собираемых в бранчи, отменяются.
- Задачу обновляемости предлагается решать следующим образом:
- для указания предпочтения пакетов из того или иного репозитория использовать механизм apt preferences;
- конфигурации apt, распространяемые в бранчах и дистрибутивах, поставлять заранее настроенными на соответствующий бранч.
- Задачу идентификации предлагается решать следующим образом:
- girar, rpm-build: имя целевого бранча каждого бинарного пакета указывать при сборке автоматически в RPMTAG_DISTRIBUTION (в формате "ALT Sisyphus") и RPMTAG_DISTTAG (например, в формате "dist.task.subtask") в дополнение к информации, уже указываемой в RPMTAG_BUILDHOST;
- girar: в начале каждой сборки подзадания автоматически генерировать уникальный идентификатор (например, "dist.task.subtask.try.iter"), и передавать его в сборочную среду через $RPM_STRICT_INTERDEPS;
- rpm-build: во время формирования бинарных подпакетов rpm-build'ом автоматически заменять строгие зависимости между подпакетами вида "N = EVR" на ещё более строгие зависимости, основанные на $RPM_STRICT_INTERDEPS;
- girar: бинарные пакеты с одинаковыми NEVR допускать в различные бранчи только при условии, что их исходники совпадают: при сборке из gear-репозиториев совпадать должны сборочные git-тэги, в противном случае совпадать должны srpm-пакеты.
- Задачу наглядности предлагается решать следующим образом:
- rpm-build: возможно, при формировании бинарных подпакетов автоматически добавлять (часть, например, первые 36 бит) их RPMTAG_IDENTITY в имена файлов путём расширения %_build_name_fmt, или же вместо RPMTAG_IDENTITY можно добавлять +b$N, где $N — порядковый номер пересборки пакета для данного бранча;
- rpm: добавить RPMTAG_NEVRI и/или RPMTAG_NEVRAI, использовать их вместо RPMTAG_NEVR и RPMTAG_NEVRA везде, где это имеет смысл.
- girar: Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить rebuild исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); при этом в changelog собранных бинарных пакетов следует автоматически вносить запись о факте пересборки. Если по результатам rebuild у всех собранных бинарных пакетов не изменился RPMTAG_IDENTITY, то считать, что пакеты не изменились, и присваивать статус сборки соответствующего subtask FAILED.
- girar: Копирование пакетов предлагается запретить полностью. Для сохранения обратной совместимости girar-интерфейса предлагается изменить операцию copy таким образом, чтобы она приводила к пересборке пакета из исходного бранча в целевой.
- girar: Для каждого бранча в дополнение к индексу исходных пакетов предлагается одновременно поддерживать и индекс бинарных пакетов.
- girar: Чтобы обеспечить проверку, что сборка пакетов с одинаковыми NEVR в разные бранчи производится только из одного и того же исходника, для каждой сборки пакета дополнительно в индекс бинарного пакета дописывать релизный хэш, предварённый схемой сборки (gear и srpm), отделённой от него двоеточием. Для сборки из gear-репозитория это хэш является commit id подписанного тега, из которого собраны пакеты, а для sourcerpm — некая контрольная сумма от него (например, SHA1). Перед самой сборкой пакета в любой бранч проверять наличие его NEVR в индексе, и в случае наличия проверять достоверность схемы сборки и хэша; в случае несоответствия сборку запретить (можно ввести новый вид ошибки, например, SOURCEMISMATCH). Если для данного NEVR в индексе исходных пакетов отсутствует релизный хэш, то его сборку в другие бранчи запретить.