Binary package identity change: различия между версиями
Ldv (обсуждение | вклад) (formatting) |
Ldv (обсуждение | вклад) (Предлагаемые изменения идентификации собранных пакетов: RPMTAG_COOKIE) |
||
Строка 21: | Строка 21: | ||
# Задачу идентификации предлагается решать следующим образом: | # Задачу идентификации предлагается решать следующим образом: | ||
## имя целевого бранча каждого бинарного пакета предлагается указывать при сборке автоматически в rpm-тэге <tt>DISTRIBUTION</tt> и <tt>DISTTAG</tt> в дополнение к информации, уже указываемой в rpm-тэге <tt>BUILDHOST</tt>; | ## имя целевого бранча каждого бинарного пакета предлагается указывать при сборке автоматически в rpm-тэге <tt>DISTRIBUTION</tt> и <tt>DISTTAG</tt> в дополнение к информации, уже указываемой в rpm-тэге <tt>BUILDHOST</tt>; | ||
## при формировании бинарных | ## при формировании бинарных подпакетов предлагается автоматически генерировать Binary Packages Identifier и сохранять его в rpm-тэге <tt>COOKIE</tt>; зависимости между подпакетами предлагается изменять автоматически во время сборки с EVR на зависимости, основанные на этом идентификаторе; | ||
## бинарные пакеты с одинаковыми NEVR предлагается допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные тэги, в противном случае совпадать должны srpm-пакеты. | ## бинарные пакеты с одинаковыми NEVR предлагается допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные тэги, в противном случае совпадать должны srpm-пакеты. | ||
# Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить <tt>rebuild</tt> исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); при этом в changelog собранных бинарных пакетов следует автоматически вносить запись о факте пересборки. | # Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить <tt>rebuild</tt> исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); при этом в changelog собранных бинарных пакетов следует автоматически вносить запись о факте пересборки. |
Версия от 23:05, 31 октября 2017
Действующие правила именования релизов собранных пакетов
Правила нумерации релизов пакетов, собираемых в бранчи, изначально были введены для решения следующих задач:
- Обновляемость: каждый бинарный пакет из более старого бранча должен был обновляться до одноимённого пакета из более свежего бранча.
- Идентификация: набор NEVR каждого бинарного пакета должен был однозначно определять целевой бранч, в который этот пакет был собран, а также исходный пакет, из которого была выполнена сборка.
- Наглядность: имя целевого бранча каждого бинарного пакета должно было быть видно там, где виден номер релиза этого пакета.
Проблемы традиционного именования релизов собранных пакетов
Однако со временем число бранчей выросло, а их линейный (а порой даже частичный) порядок был утрачен. Сейчас ответ на вопрос, какой бранч свежее, уже фактически переложен на администратора системы. Для поддержки сборок из одних и тех же исходников в разные бранчи возникли конструкции вроде %ubt, отрицательно влияющие на воспроизводимость сборки. В то же время, копирование пакетов также регулярно приводит к проблемам как в пересобираемости, так и в работоспособности скопированного. Очевидно, что Backports_Policy устарел.
Предлагаемые изменения идентификации собранных пакетов
Предлагается изменить правила следующим образом:
- Правила нумерации релизов пакетов, собираемых в бранчи, отменяются.
- Задачу обновляемости предлагается решать следующим образом:
- для указания предпочтения пакетов из того или иного репозитория предлагается использовать механизм apt preferences;
- конфигурации apt, распространяемые в бранчах и дистрибутивах, предлагается распространять заранее настроенными на соответствующий бранч.
- Задачу идентификации предлагается решать следующим образом:
- имя целевого бранча каждого бинарного пакета предлагается указывать при сборке автоматически в rpm-тэге DISTRIBUTION и DISTTAG в дополнение к информации, уже указываемой в rpm-тэге BUILDHOST;
- при формировании бинарных подпакетов предлагается автоматически генерировать Binary Packages Identifier и сохранять его в rpm-тэге COOKIE; зависимости между подпакетами предлагается изменять автоматически во время сборки с EVR на зависимости, основанные на этом идентификаторе;
- бинарные пакеты с одинаковыми NEVR предлагается допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные тэги, в противном случае совпадать должны srpm-пакеты.
- Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить rebuild исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); при этом в changelog собранных бинарных пакетов следует автоматически вносить запись о факте пересборки.
- Копирование пакетов предлагается запретить полностью. Для сохранения обратной совместимости girar-интерфейса предлагается изменить операцию copy таким образом, чтобы она приводила к пересборке пакета из исходного бранча в целевой.
- Для каждого бранча в дополнение к индексу исходных пакетов предлагается одновременно поддерживать и индекс бинарных пакетов.