Binary package identity change: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
(update)
Строка 1: Строка 1:
Очевидно, что [[Backports_Policy]] устарел. Бранечей мало того, что стало много, они ещё и потеряли очевидный порядок "старшинства". Для поддержки сборок из одиних и тех же исходников в разные бранчи возникли конструкции вроде <tt>%ubt</tt>, отрицательно влияющие на воспроизводимость сборки. В то же время, копирование пакетов также регулярно приводит к проблемам как в пересобираемости, так и в работоспособности скопированного.
Очевидно, что [[Backports_Policy]] устарел.
Правила нумерации релизов пакетов, собираемых в бранчи, изначально были введены для решения следующих задач:
# Обновляемость: каждый бинарный пакет из более старого бранча должен был обновляться до одноимённого пакета из более свежего бранча.
# Идентификация: набор NEVR каждого бинарного пакета должен был однозначно определять целевой бранч, в который этот пакет был собран, а также исходный пакет, из которого была выполнена сборка.
# Наглядность: имя целевого бранча каждого бинарного пакета должно было быть видно там, где виден номер релиза этого пакета.


# специфичные для бранчей суффиксы отменяются
Однако со временем число бранчей выросло, а их линейный (а порой даже частичный) порядок был утрачен.
# для указания предпочтения пакетов из того или иного репозитория предполагается использовать механизм apt preferencesконфигурации apt, распространяемые в дистрибутивах должны быть настроены на нужный бранч
Сейчас ответ на вопрос, какой бранч свежее, уже фактически переложен на администратора системы.
# бранч, для которого собран пакет, будет указываться в build-host
Для поддержки сборок из одних и тех же исходников в разные бранчи возникли конструкции вроде <tt>%ubt</tt>, отрицательно влияющие на воспроизводимость сборки. В то же время, копирование пакетов также регулярно приводит к проблемам как в пересобираемости, так и в работоспособности скопированного.
# для того, чтобы правильно работали меж-подпакетные зависимости, при сборке пакета должен генерироваться некий build-id и зависимости между подпакетами должны автоматически измениться с EVR на зависимости на этот build-id
 
# таким образом, раз мы всё равно будем иметь в разных бранчах разные пакеты с одинаковым name-EVR, ничто не мешает нам разрешить это в рамках одного бранча, разрешив rebuild пакета без изменения (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); Следует научить rpm-build в таком случае создавать в changelog бинарных пакетов псевдо-запись, сообщающую о пересборке
Предлагается изменить правила следующим образом:
# копирование пакетов как таковое запрещается, только пересборка. Можно оставить для совместимости интерфейс сборочницы <tt>copy</tt>, но он будет в таком случае означать пересборку из исходного бранча в целевой.
# Правила нумерации релизов пакетов, собираемых в бранчи, отменяются.
# Задачу обновляемости предлагается решать следующим образом:
## для указания предпочтения пакетов из того или иного репозитория предлагается использовать механизм apt preferences;
## конфигурации apt, распространяемые в бранчах и дистрибутивах, предлагается распространять заранее настроенными на соответствующий бранч.
# Задачу идентификации предлагается решать следующим образом:
## имя целевого бранча каждого бинарного пакета предлагается указывать при сборке автоматически в rpm-тэге <tt>DISTTAG</tt> в дополнение к информации, уже указываемой в rpm-тэге <tt>BUILDHOST</tt>;
## при формировании бинарных пакетов предлагается генерировать Binary Package Identifiers; зависимости между подпакетами предлагается изменять автоматически во время сборки с EVR на зависимости, основанные на этих идентификаторах;
## бинарные пакеты с одинаковыми NEVR предлагается допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные тэги, в противном случае совпадать должны srpm-пакеты.
# Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить <tt>rebuild</tt> исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); при этом в changelog собранных бинарных пакетов следует автоматически вносить запись о факте пересборки.
# Копирование пакетов предлагается запретить полностью. Для сохранения обратной совместимости girar-интерфейса предлагается изменить операцию <tt>copy</tt> таким образом, чтобы она приводила к пересборке пакета из исходного бранча в целевой.
# Для каждого бранча в дополнение к индексу исходных пакетов предлагается одновременно поддерживать и индекс бинарных пакетов.
[[Категория:Branches]]
[[Категория:Branches]]

Версия от 00:20, 18 июля 2017

Очевидно, что Backports_Policy устарел. Правила нумерации релизов пакетов, собираемых в бранчи, изначально были введены для решения следующих задач:

  1. Обновляемость: каждый бинарный пакет из более старого бранча должен был обновляться до одноимённого пакета из более свежего бранча.
  2. Идентификация: набор NEVR каждого бинарного пакета должен был однозначно определять целевой бранч, в который этот пакет был собран, а также исходный пакет, из которого была выполнена сборка.
  3. Наглядность: имя целевого бранча каждого бинарного пакета должно было быть видно там, где виден номер релиза этого пакета.

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

Предлагается изменить правила следующим образом:

  1. Правила нумерации релизов пакетов, собираемых в бранчи, отменяются.
  2. Задачу обновляемости предлагается решать следующим образом:
    1. для указания предпочтения пакетов из того или иного репозитория предлагается использовать механизм apt preferences;
    2. конфигурации apt, распространяемые в бранчах и дистрибутивах, предлагается распространять заранее настроенными на соответствующий бранч.
  3. Задачу идентификации предлагается решать следующим образом:
    1. имя целевого бранча каждого бинарного пакета предлагается указывать при сборке автоматически в rpm-тэге DISTTAG в дополнение к информации, уже указываемой в rpm-тэге BUILDHOST;
    2. при формировании бинарных пакетов предлагается генерировать Binary Package Identifiers; зависимости между подпакетами предлагается изменять автоматически во время сборки с EVR на зависимости, основанные на этих идентификаторах;
    3. бинарные пакеты с одинаковыми NEVR предлагается допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные тэги, в противном случае совпадать должны srpm-пакеты.
  4. Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить rebuild исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); при этом в changelog собранных бинарных пакетов следует автоматически вносить запись о факте пересборки.
  5. Копирование пакетов предлагается запретить полностью. Для сохранения обратной совместимости girar-интерфейса предлагается изменить операцию copy таким образом, чтобы она приводила к пересборке пакета из исходного бранча в целевой.
  6. Для каждого бранча в дополнение к индексу исходных пакетов предлагается одновременно поддерживать и индекс бинарных пакетов.