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

Материал из ALT Linux Wiki
(formatting)
Строка 1: Строка 1:
Очевидно, что [[Backports_Policy]] устарел.
== Действующие правила именования релизов собранных пакетов ==
 
Правила нумерации релизов пакетов, собираемых в бранчи, изначально были введены для решения следующих задач:
Правила нумерации релизов пакетов, собираемых в бранчи, изначально были введены для решения следующих задач:
# Обновляемость: каждый бинарный пакет из более старого бранча должен был обновляться до одноимённого пакета из более свежего бранча.
# Обновляемость: каждый бинарный пакет из более старого бранча должен был обновляться до одноимённого пакета из более свежего бранча.
Строка 5: Строка 6:
# Наглядность: имя целевого бранча каждого бинарного пакета должно было быть видно там, где виден номер релиза этого пакета.
# Наглядность: имя целевого бранча каждого бинарного пакета должно было быть видно там, где виден номер релиза этого пакета.


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


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

Версия от 23:00, 31 октября 2017

Действующие правила именования релизов собранных пакетов

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

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

Проблемы традиционного именования релизов собранных пакетов

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

Предлагаемые изменения идентификации собранных пакетов

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

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