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

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


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


Предлагается изменить правила следующим образом:
Предлагается изменить правила следующим образом:
# Правила нумерации релизов пакетов, собираемых в бранчи, отменяются.
# Правила нумерации релизов пакетов, собираемых в бранчи, отменяются.
# Задачу идентификации предлагается решать следующим образом:
## {{есть}} girar: Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить <tt>rebuild</tt> исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки), включив <tt>$GIRAR_ALLOW_SAME_NEVR</tt> для соответствующих бранчей.
## {{есть}} rpm-build: во время формирования бинарных подпакетов rpm-build'ом автоматически заменять строгие зависимости между подпакетами вида <tt>"N = EVR"</tt> на ещё более строгие зависимости вида <tt>N = EVRD</tt> (от зависимостей, основанных на <tt>$RPM_STRICT_INTERDEPS</tt> было решено отказаться ввиду того, что [[altbug:35580|apt по-разному обрабатывает зависимости на виртуальные и реальные пакеты]]);
##* Реализованный сейчас вариант использует в качестве формата более строгих зависимостей (и основного идентификатора/Provides пакета): <code>N = E:V-R:D</code>, где <code>D</code> -- disttag. См. [[transition to disttag]], чтобы узнать с какими трудностями связан переход на такую схему..
## {{есть}} girar: При создании подзаданий дополнительно создавать файл $task/gears/$subtask/sid -- source identifier в формате type:hash, где type описывает схему сборки (gear и srpm). Для сборки из gear-репозитория этот хэш является <tt>tag id</tt> подписанного тега, из которого собраны пакеты, а для sourcerpm — значение его RPMTAG_SHA1HEADER.
## {{есть}} girar: Чтобы обеспечить проверку того, что сборка пакетов с одинаковыми NEVR в разные бранчи производится ''только из одного и того же'' исходника, для каждой сборки пакета дополнительно в [http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/ индекс исходных пакетов] дописывать $task/gears/$subtask/sid.
## {{есть}} girar: Во время обработки задания после того, как пакет собран, проверять наличие его NEVR в [http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/ индексе исходных пакетов], и в случае наличия проверять достоверность схемы сборки и хэша; в случае несоответствия сборку запретить и перевести в состояние FAILED.
## {{есть}} girar: Такую же проверку следует сделать для сборки из sourcerpm перед сборкой пакета для экономии времени. Если для данного NEVR в [http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/ индексе исходных пакетов] релизный хэш пустой, то его сборку в другие бранчи запретить.
## {{есть}} girar, rpm-build: Имя целевого бранча каждого бинарного пакета указывать при сборке автоматически в <tt>RPMTAG_DISTRIBUTION</tt> (в формате <tt>"ALT Sisyphus"</tt>) и <tt>RPMTAG_DISTTAG</tt> (в формате <tt>"dist+task.subtask.try.iter"</tt>) в дополнение к информации, уже указываемой в <tt>RPMTAG_BUILDHOST</tt>;
## {{есть}} rpm: писать при установке/удалении пакета значение его <tt>RPMTAG_DISTTAG</tt>, если оно присутствует в пакете;
## {{есть}} (не в сборочнице) girar: Бинарные пакеты с одинаковыми NEVR допускать в различные бранчи только при условии, что их исходники совпадают: при сборке из gear-репозиториев совпадать должны сборочные git-тэги, в противном случае совпадать должны srpm-пакеты.
## {{есть}} girar: При использовании команды <tt>copy</tt> в бранч осуществлять пересборку пакета в окружении целевого бранча;
##* '''TBD''' если по результатам сборки RPMTAG_IDENTITY всех подпакетов совпадает с таковым из подпакетов, собранных из исходного бранча, осуществлять копирование их в целевой бранч, иначе класть результат сборки. Также возможно проверять RPMTAG_IDENTITY подпакетов из предыдущих итераций сборки исходного бранча с целью поиска кандидатов на копирование, время сборки которых было не раньше времени последней сборки данного NEVR в целевой бранч, если таковой NEVR имеется.
## '''TBD''': girar: Если по результатам rebuild у всех собранных бинарных пакетов не изменился RPMTAG_IDENTITY, то считать, что пакеты не изменились, и присваивать статус сборки соответствующего subtask FAILED или EPERM (необходимо в <tt>rpm.org</tt> реализовать <tt>RPMTAG_IDENTITY</tt>).
# Задачу обновляемости предлагается решать следующим образом:
# Задачу обновляемости предлагается решать следующим образом:
## для указания предпочтения пакетов из того или иного репозитория предлагается использовать механизм apt preferences;
## При наличии на целевой системе и в репозитории разных сборок пакетов с одинаковым NEVR сравнивать бранчи, в которые эти пакеты собраны, побеждает более приоритетный бранч. Если бранчи совпадают, побеждает более свежая сборка пакета;
## конфигурации apt, распространяемые в бранчах и дистрибутивах, предлагается распространять заранее настроенными на соответствующий бранч.
## Ввести механизм приоритизации бранчей.
# Задачу идентификации предлагается решать следующим образом:
# Задачу наглядности предлагается решать следующим образом:
## имя целевого бранча каждого бинарного пакета предлагается указывать при сборке автоматически в rpm-тэге <tt>DISTRIBUTION</tt> и <tt>DISTTAG</tt> в дополнение к информации, уже указываемой в rpm-тэге <tt>BUILDHOST</tt>;
## rpm: добавить <tt>RPMTAG_NEVRD</tt> и/или <tt>RPMTAG_NEVRDA</tt>, использовать их вместо <tt>RPMTAG_NEVR</tt> и <tt>RPMTAG_NEVRA</tt> везде, где это имеет смысл.
## при формировании бинарных пакетов предлагается автоматически генерировать Binary Package Identifiers и сохранять их в каком-нибудь rpm-тэге; зависимости между подпакетами предлагается изменять автоматически во время сборки с EVR на зависимости, основанные на этих идентификаторах;
## rpm-build: формировать имена пакетов в виде <tt>N-V.R.D.A.rpm</tt>.
## бинарные пакеты с одинаковыми NEVR предлагается допускать в различные бранчи только при условии, что их исходники совпадают; при сборке из gear-репозиториев совпадать должны сборочные тэги, в противном случае совпадать должны srpm-пакеты.
# Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить <tt>rebuild</tt> исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки); при этом в changelog собранных бинарных пакетов следует автоматически вносить запись о факте пересборки.
# Копирование пакетов предлагается запретить полностью.  Для сохранения обратной совместимости girar-интерфейса предлагается изменить операцию <tt>copy</tt> таким образом, чтобы она приводила к пересборке пакета из исходного бранча в целевой.
# Для каждого бранча в дополнение к [http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/ индексу исходных пакетов] предлагается одновременно поддерживать и индекс бинарных пакетов.
[[Категория:Branches]]
[[Категория:Branches]]
[[Категория:Changes]]

Текущая версия от 00:14, 15 июня 2019

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

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

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

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

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

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

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

  1. Правила нумерации релизов пакетов, собираемых в бранчи, отменяются.
  2. Задачу идентификации предлагается решать следующим образом:
    1. Symbol support vote.svg  girar: Поскольку ожидается появление разных бинарных пакетов с одинаковыми NEVR в разных бранчах, предлагается разрешить rebuild исходных пакетов без внесения в них изменений (хотя, естественно, результат может получиться отличающимся от результата предыдущей сборки), включив $GIRAR_ALLOW_SAME_NEVR для соответствующих бранчей.
    2. Symbol support vote.svg  rpm-build: во время формирования бинарных подпакетов rpm-build'ом автоматически заменять строгие зависимости между подпакетами вида "N = EVR" на ещё более строгие зависимости вида N = EVRD (от зависимостей, основанных на $RPM_STRICT_INTERDEPS было решено отказаться ввиду того, что apt по-разному обрабатывает зависимости на виртуальные и реальные пакеты);
      • Реализованный сейчас вариант использует в качестве формата более строгих зависимостей (и основного идентификатора/Provides пакета): N = E:V-R:D, где D -- disttag. См. transition to disttag, чтобы узнать с какими трудностями связан переход на такую схему..
    3. Symbol support vote.svg  girar: При создании подзаданий дополнительно создавать файл $task/gears/$subtask/sid -- source identifier в формате type:hash, где type описывает схему сборки (gear и srpm). Для сборки из gear-репозитория этот хэш является tag id подписанного тега, из которого собраны пакеты, а для sourcerpm — значение его RPMTAG_SHA1HEADER.
    4. Symbol support vote.svg  girar: Чтобы обеспечить проверку того, что сборка пакетов с одинаковыми NEVR в разные бранчи производится только из одного и того же исходника, для каждой сборки пакета дополнительно в индекс исходных пакетов дописывать $task/gears/$subtask/sid.
    5. Symbol support vote.svg  girar: Во время обработки задания после того, как пакет собран, проверять наличие его NEVR в индексе исходных пакетов, и в случае наличия проверять достоверность схемы сборки и хэша; в случае несоответствия сборку запретить и перевести в состояние FAILED.
    6. Symbol support vote.svg  girar: Такую же проверку следует сделать для сборки из sourcerpm перед сборкой пакета для экономии времени. Если для данного NEVR в индексе исходных пакетов релизный хэш пустой, то его сборку в другие бранчи запретить.
    7. Symbol support vote.svg  girar, rpm-build: Имя целевого бранча каждого бинарного пакета указывать при сборке автоматически в RPMTAG_DISTRIBUTION (в формате "ALT Sisyphus") и RPMTAG_DISTTAG (в формате "dist+task.subtask.try.iter") в дополнение к информации, уже указываемой в RPMTAG_BUILDHOST;
    8. Symbol support vote.svg  rpm: писать при установке/удалении пакета значение его RPMTAG_DISTTAG, если оно присутствует в пакете;
    9. Symbol support vote.svg  (не в сборочнице) girar: Бинарные пакеты с одинаковыми NEVR допускать в различные бранчи только при условии, что их исходники совпадают: при сборке из gear-репозиториев совпадать должны сборочные git-тэги, в противном случае совпадать должны srpm-пакеты.
    10. Symbol support vote.svg  girar: При использовании команды copy в бранч осуществлять пересборку пакета в окружении целевого бранча;
      • TBD если по результатам сборки RPMTAG_IDENTITY всех подпакетов совпадает с таковым из подпакетов, собранных из исходного бранча, осуществлять копирование их в целевой бранч, иначе класть результат сборки. Также возможно проверять RPMTAG_IDENTITY подпакетов из предыдущих итераций сборки исходного бранча с целью поиска кандидатов на копирование, время сборки которых было не раньше времени последней сборки данного NEVR в целевой бранч, если таковой NEVR имеется.
    11. TBD: girar: Если по результатам rebuild у всех собранных бинарных пакетов не изменился RPMTAG_IDENTITY, то считать, что пакеты не изменились, и присваивать статус сборки соответствующего subtask FAILED или EPERM (необходимо в rpm.org реализовать RPMTAG_IDENTITY).
  3. Задачу обновляемости предлагается решать следующим образом:
    1. При наличии на целевой системе и в репозитории разных сборок пакетов с одинаковым NEVR сравнивать бранчи, в которые эти пакеты собраны, побеждает более приоритетный бранч. Если бранчи совпадают, побеждает более свежая сборка пакета;
    2. Ввести механизм приоритизации бранчей.
  4. Задачу наглядности предлагается решать следующим образом:
    1. rpm: добавить RPMTAG_NEVRD и/или RPMTAG_NEVRDA, использовать их вместо RPMTAG_NEVR и RPMTAG_NEVRA везде, где это имеет смысл.
    2. rpm-build: формировать имена пакетов в виде N-V.R.D.A.rpm.