Backports Policy: различия между версиями

Материал из ALT Linux Wiki
(Дисциплина полностью переписана под современные реалии. Старый тескт пока в комментариях, но он скорее всего не нужен.)
(Пояснение про disttag и _priority_distbranch)
Строка 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), что и в исходном репозитории. Приоритет таких пакетов определяется по [[Transition_to_disttag|disttag]] и [[Branches#/etc/rpm/macros.d/|%_priority_distbranch]].
В этом случае ничего в спеке менять не надо (иначе это приведёт к изменению  Source ID), пакет будет пересобран и помещён в репозиторий с тем же идентификатором [[Binary_package_identity_change|Name-Epoch-Version-Release]] (NEVR), что и в исходном репозитории.
 
Полученный таким образом бинарный пакет будет заведомо отличаться от исходного, в том числе полями [[Transition_to_disttag|disttag]] и [[Branches#/etc/rpm/macros.d/|%_priority_distbranch]], которые будут определять его приоритет при обновлении.


== Оформление бекпорта ==
== Оформление бекпорта ==

Версия от 18:56, 23 ноября 2021

Stub.png
Черновик политики Sisyphus
Автор(ы) — cas@, glebfm@, george@, mike@
Обсуждение в devel@
Обсуждается с 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» не срабатывает — здесь поможет только здравый смысл.
  • Если пакет приходится сопровождать в рамках репозитория, изменяется часть «Релиз_в_репозитории».
    • В первом примере выше после очередных правок релиз пакета станет «-alt0.p10.2».

В остальном спек оформляется согласно общим правилам.

Сборка

  • Сборка пакета в стабильный репозиторий отличается только указанием названия репозитория в командах сборочницы.
  • Как правило, права на сборку в стабильный репозиторий есть не у всех членов Team, и соответствующее успешное задание должно быть одобрено командой, сопровождающей конкретный репозиторий (например, сначала пройти тестирование).