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

Материал из ALT Linux Wiki
(RPMTAG_IDENTITY)
Строка 22: Строка 22:
## имя целевого бранча каждого бинарного пакета указывать при сборке автоматически в <tt>RPMTAG_DISTRIBUTION</tt> (в формате <tt>"ALT Sisyphus"</tt>) и <tt>RPMTAG_DISTTAG</tt> (в формате <tt>"dist.owner.task.subtask"</tt>) в дополнение к информации, уже указываемой в <tt>RPMTAG_BUILDHOST</tt>;
## имя целевого бранча каждого бинарного пакета указывать при сборке автоматически в <tt>RPMTAG_DISTRIBUTION</tt> (в формате <tt>"ALT Sisyphus"</tt>) и <tt>RPMTAG_DISTTAG</tt> (в формате <tt>"dist.owner.task.subtask"</tt>) в дополнение к информации, уже указываемой в <tt>RPMTAG_BUILDHOST</tt>;
## в начале каждой сборки подзадания автоматически генерировать уникальный идентификатор (например, хэш от <tt>"dist.owner.task.subtask.try.iter"</tt>), и передавать его в сборочную среду; имя этому уникальному идентификатору ещё предстоит придумать;
## в начале каждой сборки подзадания автоматически генерировать уникальный идентификатор (например, хэш от <tt>"dist.owner.task.subtask.try.iter"</tt>), и передавать его в сборочную среду; имя этому уникальному идентификатору ещё предстоит придумать;
## при формировании бинарных подпакетов rpm-build'ом автоматически вычислять для каждого подпакета <tt>RPMTAG_IDENTITY</tt> -- хэш тех же данных, по которым вычисляется <tt>RPMTAG_SHA1HEADER</tt>, за вычетом некоторых тэгов (таких как <tt>RPMTAG_BUILDTIME</tt> и <tt>RPMTAG_BUILDHOST</tt>);
## ввести новый тэг <tt>RPMTAG_IDENTITY</tt>; при формировании бинарных подпакетов rpm-build'ом автоматически вычислять для каждого подпакета <tt>RPMTAG_IDENTITY</tt> -- хэш тех же данных, по которым вычисляется <tt>RPMTAG_SHA1HEADER</tt>, за вычетом некоторых тэгов (таких как <tt>RPMTAG_BUILDTIME</tt> и <tt>RPMTAG_BUILDHOST</tt>);
## при наличии уникального идентификатора на момент формирования бинарных подпакетов rpm-build'ом после вычисления <tt>RPMTAG_IDENTITY</tt> автоматически заменять строгие зависимости между подпакетами вида <tt>"N = EVR"</tt> на ещё более строгие зависимости, основанные на этом уникальном идентификаторе, например, вида <tt>".hash_N"</tt>;
## во время формирования бинарных подпакетов rpm-build'ом после вычисления <tt>RPMTAG_IDENTITY</tt> автоматически заменять строгие зависимости между подпакетами вида <tt>"N = EVR"</tt> на ещё более строгие зависимости, основанные на <tt>RPMTAG_IDENTITY</tt>, например, вида <tt>".hash_N"</tt>;
## если во время формирования бинарных подпакетов rpm-build'ом образуются noarch-подпакеты, строго зависящие от arch-подпакетов, или, наоборот, arch-подпакеты, строго зависящие от noarch-подпакетов, то при наличии уникального идентификатора автоматически заменять эти зависимости на ещё более строгие зависимости, основанные на этом уникальном идентификаторе, а не на <tt>RPMTAG_IDENTITY</tt>;
## бинарные пакеты с одинаковыми NEVR допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные git-тэги, в противном случае совпадать должны srpm-пакеты.
## бинарные пакеты с одинаковыми NEVR допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные git-тэги, в противном случае совпадать должны srpm-пакеты.
# Задачу наглядности предлагается решать следующим образом:
# Задачу наглядности предлагается решать следующим образом:

Версия от 03:21, 29 ноября 2017

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

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

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

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

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

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

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

  1. Правила нумерации релизов пакетов, собираемых в бранчи, отменяются.
  2. Задачу обновляемости предлагается решать следующим образом:
    1. для указания предпочтения пакетов из того или иного репозитория использовать механизм apt preferences;
    2. конфигурации apt, распространяемые в бранчах и дистрибутивах, поставлять заранее настроенными на соответствующий бранч.
  3. Задачу идентификации предлагается решать следующим образом:
    1. имя целевого бранча каждого бинарного пакета указывать при сборке автоматически в RPMTAG_DISTRIBUTION (в формате "ALT Sisyphus") и RPMTAG_DISTTAG (в формате "dist.owner.task.subtask") в дополнение к информации, уже указываемой в RPMTAG_BUILDHOST;
    2. в начале каждой сборки подзадания автоматически генерировать уникальный идентификатор (например, хэш от "dist.owner.task.subtask.try.iter"), и передавать его в сборочную среду; имя этому уникальному идентификатору ещё предстоит придумать;
    3. ввести новый тэг RPMTAG_IDENTITY; при формировании бинарных подпакетов rpm-build'ом автоматически вычислять для каждого подпакета RPMTAG_IDENTITY -- хэш тех же данных, по которым вычисляется RPMTAG_SHA1HEADER, за вычетом некоторых тэгов (таких как RPMTAG_BUILDTIME и RPMTAG_BUILDHOST);
    4. во время формирования бинарных подпакетов rpm-build'ом после вычисления RPMTAG_IDENTITY автоматически заменять строгие зависимости между подпакетами вида "N = EVR" на ещё более строгие зависимости, основанные на RPMTAG_IDENTITY, например, вида ".hash_N";
    5. если во время формирования бинарных подпакетов rpm-build'ом образуются noarch-подпакеты, строго зависящие от arch-подпакетов, или, наоборот, arch-подпакеты, строго зависящие от noarch-подпакетов, то при наличии уникального идентификатора автоматически заменять эти зависимости на ещё более строгие зависимости, основанные на этом уникальном идентификаторе, а не на RPMTAG_IDENTITY;
    6. бинарные пакеты с одинаковыми NEVR допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные git-тэги, в противном случае совпадать должны srpm-пакеты.
  4. Задачу наглядности предлагается решать следующим образом:
    1. при формировании бинарных подпакетов rpm-build'ом автоматически добавлять (часть, например, первые 36 бит) их RPMTAG_IDENTITY в имена файлов путём расширения %_build_name_fmt;
    2. добавить RPMTAG_NEVRI и/или RPMTAG_NEVRAI, использовать их вместо RPMTAG_NEVR и RPMTAG_NEVRA везде, где это имеет смысл.
  5. Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить rebuild исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); при этом в changelog собранных бинарных пакетов следует автоматически вносить запись о факте пересборки.
  6. Копирование пакетов предлагается запретить полностью. Для сохранения обратной совместимости girar-интерфейса предлагается изменить операцию copy таким образом, чтобы она приводила к пересборке пакета из исходного бранча в целевой.
  7. Для каждого бранча в дополнение к индексу исходных пакетов предлагается одновременно поддерживать и индекс бинарных пакетов.