Backports Policy: различия между версиями
(Дисциплина полностью переписана под современные реалии. Старый тескт пока в комментариях, но он скорее всего не нужен.) |
|||
(не показаны 3 промежуточные версии этого же участника) | |||
Строка 24: | Строка 24: | ||
Если возможна успешная сборка пакета из исходников, ''полностью совпадающих'' с аналогичным пакетом в Sisyphus (т. е. имеющим тот же Source ID), например, из того же тега в git-е, рекомендуется пользоваться механизмом сборочницы <tt>[[Справочник_по_git.alt#task|task … copy]]</tt>. | Если возможна успешная сборка пакета из исходников, ''полностью совпадающих'' с аналогичным пакетом в Sisyphus (т. е. имеющим тот же Source ID), например, из того же тега в git-е, рекомендуется пользоваться механизмом сборочницы <tt>[[Справочник_по_git.alt#task|task … copy]]</tt>. | ||
В этом случае ничего в спеке менять не надо (иначе это приведёт к изменению Source ID), пакет будет пересобран и помещён в репозиторий с тем же идентификатором [[Binary_package_identity_change|Name-Epoch-Version-Release]] (NEVR), что и в исходном репозитории. | В этом случае ничего в спеке менять не надо (иначе это приведёт к изменению Source ID), пакет будет пересобран и помещён в репозиторий с тем же идентификатором [[Binary_package_identity_change|Name-Epoch-Version-Release]] (NEVR), что и в исходном репозитории. | ||
Полученный таким образом бинарный пакет будет заведомо отличаться от бинарного пакета в исходном репозитории, в том числе полями [[Transition_to_disttag|disttag]] и [[Branches#/etc/rpm/macros.d/|%_priority_distbranch]], которые определяют его приоритет при обновлении. | |||
== Оформление бекпорта == | == Оформление бекпорта == | ||
Строка 31: | Строка 33: | ||
'''Требования''' к полю Release: | '''Требования''' к полю Release: | ||
* Отличие ''должно быть'' (разные исходники — разные NEVR) | * Отличие ''должно быть'' (разные исходники — разные NEVR) | ||
* Релиз бекпорта должен быть ''версионно меньше'' релиза исходного пакета | * Релиз бекпорта должен быть ''версионно меньше'' релиза исходного пакета | ||
'''Рекомендации''' по именованию релиза: | '''Рекомендации''' по именованию релиза: | ||
* Предлагается формат «<tt>(Исходный_релиз-1).(Название_репозитория).(Релиз_в_репозитории)</tt>» | * Предлагается формат «<tt>(Исходный_релиз-1).(Название_репозитория).(Релиз_в_репозитории)</tt>» | ||
** Например, если исходный релиз был «<tt>-alt1</tt>», то релиз в репозитории <tt>p10</tt> будет «<tt>-alt0.p10.1</tt>». | ** Например, если исходный релиз был «<tt>-alt1</tt>», то релиз в репозитории <tt>p10</tt> будет равен «<tt>-alt0.p10.1</tt>». | ||
* Бывают случаи (например, «<tt>-alt0.git0ea78d</tt>»), когда правило «-1» не срабатывает — здесь поможет только здравый смысл. | * Бывают случаи (например, «<tt>-alt0.git0ea78d</tt>»), когда правило «-1» не срабатывает — здесь поможет только здравый смысл. | ||
** (возможно, здравый смысл стоило проявить ранее, и в исходном пакете добавить .1 — «<tt>-alt0.git0ea78d.1</tt>») | |||
* Если пакет приходится сопровождать в рамках репозитория, изменяется часть «<tt>Релиз_в_репозитории</tt>». | * Если пакет приходится сопровождать в рамках репозитория, изменяется часть «<tt>Релиз_в_репозитории</tt>». | ||
** В первом примере выше после очередных правок релиз | ** В первом примере выше после очередных правок того же пакета его релиз станет «<tt>-alt0.p10.2</tt>». | ||
* При очередном бекпорте нового релиза из исходного репозитория продолжает соблюдаться правило «-1», а поле «Релиз_в_репозитории» сбрасывается в '''1''' | |||
** Например, если в предыдущем примере было принято решение о бекпортировании следующего релиза «<tt>-alt2</tt>», то поле «Release» в <tt>p10</tt> будет равно «<tt>-alt1.p10.1</tt>». | |||
В остальном спек оформляется согласно [[Spec|общим правилам]]. | В остальном спек оформляется согласно [[Spec|общим правилам]]. |
Версия от 19:17, 23 ноября 2021
Backports policy
Этот документ регламентирует правила оформления, сборки и публикации пакетов в стабильные репозитории ALT Linux Team.
Назначение репозитория
Репозиторий созаётся для хранения пакетов, предназначенных для формирования соответствующего семейства дистрибутивов. Для каждого семейства дистрибутивов создается отдельный репозиторий. Список репозиториев можно получить, например, с помощью команды сборочнице task new --help
В настоящее время это c9f1, c9f2, c9m2, p8, p9 и p10.
Часть пакетов репозитория не изменяется с момента его возникновения, несмотря на выход новых версий, другая часть — обновляется или как минимум модифицируется (например, из соображений безопасности).
«Копирование» пакетов
Если возможна успешная сборка пакета из исходников, полностью совпадающих с аналогичным пакетом в Sisyphus (т. е. имеющим тот же Source ID), например, из того же тега в git-е, рекомендуется пользоваться механизмом сборочницы task … copy.
В этом случае ничего в спеке менять не надо (иначе это приведёт к изменению Source ID), пакет будет пересобран и помещён в репозиторий с тем же идентификатором Name-Epoch-Version-Release (NEVR), что и в исходном репозитории.
Полученный таким образом бинарный пакет будет заведомо отличаться от бинарного пакета в исходном репозитории, в том числе полями disttag и %_priority_distbranch, которые определяют его приоритет при обновлении.
Оформление бекпорта
Если пакет невозможно собрать в стабильный репозиторий без изменения исходных текстов — требуются патчи, изменения списка зависимостей или названия инструментов в спеке, модификация документации и т. п. — пакет обязан иметь другой NEVR, конкретно — отличаться полем «Release».
Требования к полю Release:
- Отличие должно быть (разные исходники — разные NEVR)
- Релиз бекпорта должен быть версионно меньше релиза исходного пакета
Рекомендации по именованию релиза:
- Предлагается формат «(Исходный_релиз-1).(Название_репозитория).(Релиз_в_репозитории)»
- Например, если исходный релиз был «-alt1», то релиз в репозитории p10 будет равен «-alt0.p10.1».
- Бывают случаи (например, «-alt0.git0ea78d»), когда правило «-1» не срабатывает — здесь поможет только здравый смысл.
- (возможно, здравый смысл стоило проявить ранее, и в исходном пакете добавить .1 — «-alt0.git0ea78d.1»)
- Если пакет приходится сопровождать в рамках репозитория, изменяется часть «Релиз_в_репозитории».
- В первом примере выше после очередных правок того же пакета его релиз станет «-alt0.p10.2».
- При очередном бекпорте нового релиза из исходного репозитория продолжает соблюдаться правило «-1», а поле «Релиз_в_репозитории» сбрасывается в 1
- Например, если в предыдущем примере было принято решение о бекпортировании следующего релиза «-alt2», то поле «Release» в p10 будет равно «-alt1.p10.1».
В остальном спек оформляется согласно общим правилам.
Сборка
- Сборка пакета в стабильный репозиторий отличается только указанием названия репозитория в командах сборочницы.
- Как правило, права на сборку в стабильный репозиторий есть не у всех членов Team, и соответствующее успешное задание должно быть одобрено командой, сопровождающей конкретный репозиторий (например, сначала пройти тестирование).