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

Материал из ALT Linux Wiki
м (замечание насчёт disttag)
(Дисциплина полностью переписана под современные реалии. Старый тескт пока в комментариях, но он скорее всего не нужен.)
Строка 1: Строка 1:
{{DraftPolicy
{{DraftPolicy
|responsible=alb@, dottedmag@, mike@, raorn@
|responsible=cas@, glebfm@, george@, mike@
|discussion_link=http://lists.altlinux.org/pipermail/backports/2005-February/005271.html
|discussion_link=https://lore.altlinux.org/devel/YQFM7vFVjISyQLV7@glebfm.cloud.tilaa.com/T/#u
|discussion_since=2004
|discussion_since=2021
}}
}}


==  Backports policy ==
==  Backports policy ==


Этот документ регламентирует назначение репозитория бэкпортов, его структуру, порядок помещения пакетов в репозиторий стабильной ветки, а также требования, которым должен соответствовать пакет.
Этот документ регламентирует правила оформления, сборки и публикации пакетов в [[Branches|стабильные репозитории]] ALT Linux Team.


{{attention|После [[Binary package identity change|перехода на disttag]] делать полномасштабные бэкпорты, если технически они подразумевают пересборку того же исходного пакета в другом окружении, а не именно адаптацию под особенности ветки -- стало излишне; пользуйтесь командой <tt>[[Справочник_по_git.alt#task|copy]]</tt>, которая была изменена так, что обеспечивает пересборку.}}
<!--
{{attention|После [[Binary package identity change|перехода на disttag]] делать полномасштабные бэкпорты, если технически они подразумевают пересборку того же исходного пакета в другом окружении, а не именно адаптацию под особенности ветки - стало излишне; пользуйтесь командой <tt>[[Справочник_по_git.alt#task|copy]]</tt>, которая была изменена так, что обеспечивает пересборку.}}
-->


== Назначение репозитория ==
== Назначение репозитория ==
Репозиторий предназначен для хранения портированных на соответствующее семейство дистрибутивов пакетов. Для каждого семейства дистрибутивов создается отдельный репозиторий. В настоящее время существуют репозитории для следующих дистрибутивов:
[[Branches|Репозиторий]] созаётся для хранения пакетов, предназначенных для формирования соответствующего семейства дистрибутивов. Для каждого семейства дистрибутивов создается отдельный репозиторий. Список репозиториев можно получить, например, с помощью команды сборочнице <tt>[[Справочник_по_git.alt#task|task new --help]]</tt>
 
В настоящее время это c9f1, c9f2, c9m2, p8, p9 и [[Десятая_платформа|p10]].
 
Часть пакетов репозитория не изменяется с момента его возникновения, несмотря на выход новых версий, другая часть — обновляется или как минимум модифицируется (например, из соображений безопасности).
 
== «Копирование» пакетов ==
 
Если возможна успешная сборка пакета из исходников, ''полностью совпадающих'' с аналогичным пакетом в 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]].
 
== Оформление бекпорта ==
Если пакет невозможно собрать в стабильный репозиторий без изменения исходных текстов — требуются патчи, изменения списка зависимостей или названия инструментов в спеке, модификация документации и т. п. — пакет обязан иметь другой NEVR, конкретно — отличаться полем «Release».
 
'''Требования''' к полю Release:
* Отличие ''должно быть'' (разные исходники — разные NEVR)
* Релиз бекпорта должен быть ''версионно меньше'' релиза исходного пакета (иначе будут проблемы с обновлением при переключении репозиториев)
'''Рекомендации''' по именованию релиза:
* Предлагается формат «<tt>(Исходный_релиз-1).(Название_репозитория).(Релиз_в_репозитории)</tt>»
** Например, если исходный релиз был «<tt>-alt1</tt>», то релиз в репозитории <tt>p10</tt> будет «<tt>-alt0.p10.1</tt>».
* Бывают случаи (например, «<tt>-alt0.git0ea78d</tt>»), когда правило «-1» не срабатывает — здесь поможет только здравый смысл.
* Если пакет приходится сопровождать в рамках репозитория, изменяется часть «<tt>Релиз_в_репозитории</tt>».
** В первом примере выше после очередных правок релиз пакета станет «<tt>-alt0.p10.2</tt>».
 
В остальном спек оформляется согласно [[Spec|общим правилам]].


* ALT Linux 4.0 Server;
== Сборка ==
* ALT Linux 3.0 Compact;
* ALT Linux 2.4 Master;
* ALT Linux 2.3 Compact, Junior (только архив);
* ALT Linux 2.2 Master (только архив).


* Сборка пакета в стабильный репозиторий отличается только указанием названия репозитория в [[Справочник_по_git.alt|командах сборочницы]].
* Как правило, права на сборку в стабильный репозиторий есть не у всех членов Team, и соответствующее успешное задание должно быть одобрено командой, сопровождающей конкретный репозиторий (например, сначала пройти тестирование).
** Текущая [[p10#Процедура_сборки_пакетов_Десятой_платформы|процедура сборки пакетов Десятой платформы]]
<!--
== Структура репозитория ==
== Структура репозитория ==
Каждый репозиторий создается с помощью утилиты <tt>genbasedir</tt>. Поддерживаемые архитектуры — i586 и i686. Для каждой из архитектур определена компонента <tt>backports</tt>. При необходимости в репозиторий могут быть добавлены другие архитектуры.
Каждый репозиторий создается с помощью утилиты <tt>genbasedir</tt>. Поддерживаемые архитектуры — i586 и i686. Для каждой из архитектур определена компонента <tt>backports</tt>. При необходимости в репозиторий могут быть добавлены другие архитектуры.
Строка 32: Строка 59:
== Помещение пакетов в репозиторий ==
== Помещение пакетов в репозиторий ==
По состоянию на 2010 год централизованная сборка backports силами mike@ прекращена.
По состоянию на 2010 год централизованная сборка backports силами mike@ прекращена.
<!--
Для получения возможности выкладывать пакеты в репозиторий необходимо быть участником команды разработчиков ALT Linux. Если вы уже в команде, ничего
Для получения возможности выкладывать пакеты в репозиторий необходимо быть участником команды разработчиков ALT Linux. Если вы уже в команде, ничего
дополнительного не требуется. Информация по присоединению к команде находится [[Join|здесь]].
дополнительного не требуется. Информация по присоединению к команде находится [[Join|здесь]].
Строка 41: Строка 67:


В случае успешной пересборки пакеты попадают в соответствующий репозиторий.
В случае успешной пересборки пакеты попадают в соответствующий репозиторий.
-->


== Требования к пакетам ==
== Требования к пакетам ==
Строка 105: Строка 130:


Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7.
Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7.
== Взаимодействие с другими репозиториями ==
== Взаимодействие с другими репозиториями ==
Если делаются не бэкпорты пакетов из Sisyphus, а существенные доработки или обновления — следует уведомить майнтейнера пакета в нём и сотрудничать с ним для сохранения добавленной функциональности.
Если делаются не бэкпорты пакетов из Sisyphus, а существенные доработки или обновления — следует уведомить майнтейнера пакета в нём и сотрудничать с ним для сохранения добавленной функциональности.
Строка 115: Строка 139:


Бэкпорт новой версии библиотеки, входящей в состав дистрибутива, может нарушить бинарную совместимость дистрибутива. Это приведет к необходимости пересборки некоторого множества входящих в дистрибутив пакетов. Такое бэкпортирование допускается, только если будет осуществлена пересборка всех зависимых пакетов.
Бэкпорт новой версии библиотеки, входящей в состав дистрибутива, может нарушить бинарную совместимость дистрибутива. Это приведет к необходимости пересборки некоторого множества входящих в дистрибутив пакетов. Такое бэкпортирование допускается, только если будет осуществлена пересборка всех зависимых пакетов.
 
-->


{{Category navigation|title=Backports|category=Backports}}
{{Category navigation|title=Backports|category=Backports}}
{{Category navigation|title=Черновики нормативных документов|category=Черновики нормативных документов|sortkey={{SUBPAGENAME}}}}
{{Category navigation|title=Черновики нормативных документов|category=Черновики нормативных документов|sortkey={{SUBPAGENAME}}}}

Версия от 15:40, 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, и соответствующее успешное задание должно быть одобрено командой, сопровождающей конкретный репозиторий (например, сначала пройти тестирование).