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

Текущая версия от 19:17, 23 ноября 2021

Черновик политики 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» не срабатывает — здесь поможет только здравый смысл.
- (возможно, здравый смысл стоило проявить ранее, и в исходном пакете добавить .1 — «-alt0.git0ea78d.1»)
Если пакет приходится сопровождать в рамках репозитория, изменяется часть «Релиз_в_репозитории».
- В первом примере выше после очередных правок того же пакета его релиз станет «-alt0.p10.2».
При очередном бекпорте нового релиза из исходного репозитория продолжает соблюдаться правило «-1», а поле «Релиз_в_репозитории» сбрасывается в 1
- Например, если в предыдущем примере было принято решение о бекпортировании следующего релиза «-alt2», то поле «Release» в p10 будет равно «-alt1.p10.1».

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

Сборка

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

Backports

Backports • Backports Policy • Cronport • Бэкпорт в Бранч • Перенос программ (backports)

Черновики нормативных документов

ACL Policy • Ada Policy • Backports Policy • Branch Policy • Desktop Environment Policy • DistroReleasePolicy • Fortune Policy • Gtk Gnome Themes Policy • Index.html Policy • Jabber Policy • JavaScript Policy • License Tag Policy • Lua Policy • Maintainer Change Policy • Mass NMU • MediaWiki Policy • Mono Policy • Node.js Policy • NonFree • OCaml Policy • Package Splitting • Packager Teams • Pear Policy • Pecl Policy • Pseudo User Policy • Python Policy • Ruby Policy 2.0 • SbindirPolicy • Security Policy • Services Policy • Shared Libs Policy • Sound Policy • Tcl Policy • TLS • TmpDir • Web Policy

@@ Строка 1: / Строка 1: @@
-[[Category:Policy]]
+{{DraftPolicy
-{{MovedFromFreesourceInfo|AltLinux/Policy/Drafts/Backports}}
+|responsible=cas@, glebfm@, george@, mike@
+|discussion_link=https://lore.altlinux.org/devel/YQFM7vFVjISyQLV7@glebfm.cloud.tilaa.com/T/#u
+|discussion_since=2021
+}}
-== Backports policy ==
+==  Backports policy ==
-{| border="1"
+Этот документ регламентирует правила оформления, сборки и публикации пакетов в [[Branches|стабильные репозитории]] ALT Linux Team.
-|-
-|
-Статус
-|
-Черновик, обсуждение не начато
-|-
-|
-Автор(ы)
-|
-''никто за проведение в жизнь пока не взялся''
-|-
-|
-Контрибутор(ы)
-|
-Михаил Шигорин (mike@), Алексей Боровской (alb@), Sir Raorn (raorn@), Mikhail Gusarov (dottedmag@)
-|-
-|
-Обязательно в
-|
-|-
+<!--
-|
+{{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]], которые определяют его приоритет при обновлении.
-== Обновление policy ==
+== Оформление бекпорта ==
-Backports policy сопровождается и обновляется участниками backports maintainers committee.
+Если пакет невозможно собрать в стабильный репозиторий без изменения исходных текстов — требуются патчи, изменения списка зависимостей или названия инструментов в спеке, модификация документации и т. п. — пакет обязан иметь другой NEVR, конкретно — отличаться полем «Release».
-Состав backports maintainers committee:
+'''Требования''' к полю Release:
-* Michael Shigorin
+* Отличие ''должно быть'' (разные исходники — разные NEVR)
-* Alexey I. Froloff (Sir Raorn)
+* Релиз бекпорта должен быть ''версионно меньше'' релиза исходного пакета
+'''Рекомендации''' по именованию релиза:
+* Предлагается формат «<tt>(Исходный_релиз-1).(Название_репозитория).(Релиз_в_репозитории)</tt>»
+** Например, если исходный релиз был «<tt>-alt1</tt>», то релиз в репозитории <tt>p10</tt> будет равен «<tt>-alt0.p10.1</tt>».
+* Бывают случаи (например, «<tt>-alt0.git0ea78d</tt>»), когда правило «-1» не срабатывает — здесь поможет только здравый смысл.
+** (возможно, здравый смысл стоило проявить ранее, и в исходном пакете добавить .1 — «<tt>-alt0.git0ea78d.1</tt>»)
+* Если пакет приходится сопровождать в рамках репозитория, изменяется часть «<tt>Релиз_в_репозитории</tt>».
+** В первом примере выше после очередных правок того же пакета его релиз станет «<tt>-alt0.p10.2</tt>».
+* При очередном бекпорте нового релиза из исходного репозитория продолжает соблюдаться правило «-1», а поле «Релиз_в_репозитории» сбрасывается в '''1'''
+** Например, если в предыдущем примере было принято решение о бекпортировании следующего релиза «<tt>-alt2</tt>», то поле «Release» в <tt>p10</tt> будет равно «<tt>-alt1.p10.1</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>. При необходимости в репозиторий могут быть добавлены другие архитектуры.
 == Расположение репозитория и доступ к нему ==
 Получить доступ к репозиторию на чтение можно несколькими способами:
 * По протоколу ftp: [ftp://ftp.altlinux.org/pub/distributions/ALTLinux/backports/ ftp://ftp.altlinux.org/pub/distributions/ALTLinux/backports/]
-* По протоколу rsync: rsync://rsync.altlinux.org::ALTLinux/backports/
+* По протоколу rsync: rsync://rsync.altlinux.org/ALTLinux/backports/
 == Помещение пакетов в репозиторий ==
+По состоянию на 2010 год централизованная сборка backports силами mike@ прекращена.
 Для получения возможности выкладывать пакеты в репозиторий необходимо быть участником команды разработчиков ALT Linux. Если вы уже в команде, ничего
 дополнительного не требуется. Информация по присоединению к команде находится [[Join|здесь]].
-Пакеты следует выкладывать на cvs.altlinux.org в один из следующих каталогов:
+Пакеты следует выкладывать на devel.altlinux.org в один из следующих каталогов:
-* для ALT Linux 2.4 и выше: /incoming/backports/2.4/ и т.п.; ответственный за сборку -- mike@
+* для ALT Linux 2.4 и выше: /incoming/backports/2.4/ и т. п.; ответственный за сборку — mike@
 * для ALT Linux 2.2 Master и ALT Linux 2.3 Compact, Junior сборка backports прекращена.
@@ Строка 71: / Строка 74: @@
 == Требования к пакетам ==
 === Сборка ===
 Пакеты должны собираться в среде [[hasher]] с подключенными репозиториями:
@@ Строка 79: / Строка 83: @@
 === Исправления spec-файла ===
-Поле Packager не должно изменяться. Всю необходимую информацию заностить в changelog.
+Поле Packager не должно изменяться. Всю необходимую информацию нужно заносить в changelog.
 Например:
@@ Строка 90: / Строка 94: @@
 Поле BuildRequires должно быть адаптировано под дистрибутив, на который производится портирование.
+В [[etersoft-build-utils]] предусмотрена команда вида <code>rpmbp -b p8</code>,
+которая выполняет необходимые преобразования спека: релиза пакета, ChangeLog, BuildRequires, Requires.
 === Правила нумерации релизов ===
-Релизы нумеруются следующим образом: <tt>ORIG_RELEASE.DISTRO.BACKPORT_RELEASE</tt>. Таким образом, полное наименование пакета будет таким: <tt>%name-%version-ORIG_RELEASE.DISTRO.BACKPORT_RELEASE</tt>
+Релизы нумеруются следующим образом: <tt>ADAPTED_RELEASE.DISTRO.BACKPORT_RELEASE</tt>. Таким образом, полное наименование пакета будет таким: <tt>%name-%version-ADAPTED_RELEASE.DISTRO.BACKPORT_RELEASE</tt>
 К примеру, первый бэкпорт пакета <tt>foo-1.0-alt1</tt> на branch/4.0 будет выглядеть как <tt>foo-1.0-alt0.M40.1</tt>.
 Где:
-* ORIG_RELEASE - строка, описывающая релиз пакета, из которого "растет" данная ветка;
+* ADAPTED_RELEASE — релиз, выбраный таким образом, что ORIG_RELEASE <= ADAPTED_RELEASE < SISYPHUS_RELEASE.
-* BACKPORT_RELEASE - номер релиза пакета внутри репозитория backports. Нумерация начинается с 1.
+: Рекомендуемое значение — SISYPHUS_RELEASE - 1.
-* DISTRO - дистрибутив, на который осуществляется портирование. Допустимые значения:
+* ORIG_RELEASE — строка, описывающая релиз пакета, из которого «растёт» данная ветка (который был переложен в бранч из Сизифа);
-** M40 - ALT Linux 4.0 Server;
+* SISYPHUS_RELEASE — релиз пакета в Сизифе, на базе которого делался backport пакет;
-** M30 - ALT Linux 3.0 Compact;
+* BACKPORT_RELEASE — номер релиза пакета внутри репозитория backports. Нумерация начинается с 1.
-** M24 - ALT Linux 2.4 Master;
+* DISTRO — репозиторий ([[Branches|бранч]]) либо дистрибутив (до ALM2.4 включительно), на который осуществляется портирование. Допустимые значения:
-** M23 - ALT Linux 2.3 Compact и ALT Linux 2.3 Junior;
+** M90P — Альт p9 (дистрибутивы на базе девятой платформы);
+** M80C — Альт СП 8 (сертифицированный дистрибутив на базе ветки с8);
+** M80P — Альт p8 (дистрибутивы на базе восьмой платформы);
+** M70C — ALT Linux СПТ 7 (сертифицированный дистрибутив на базе ветки с7);
+** M70P — ALT Linux p7 (дистрибутивы на базе седьмой платформы);
+** M60T — ALT Linux t6 (дистрибутивы на базе 6-й ветки сообщества);
+** M60P — ALT Linux p6 (дистрибутивы на базе шестой платформы);
+** M51 — ALT Linux 5.1;
+** M50P — ALT Linux p5 (дистрибутивы на базе пятой платформы);
+** M50 — ALT Linux 5.0;
+** M41 — ALT Linux 4.1;
+** M40 — ALT Linux 4.0;
+** M30 — ALT Linux 3.0 Compact;
+** M24 — ALT Linux 2.4 Master;
+** M23 — ALT Linux 2.3 Compact и ALT Linux 2.3 Junior;
-и по аналогии для веток новее 4.0.
+и по аналогии для более новых веток.
 При обновлении в бэкпортах до новой версии (%version) пакета, BACKPORTS_RELEASE сбрасывается в 1 и ORIG_RELEASE устанавливается в <tt>alt0</tt>.
@@ Строка 113: / Строка 134: @@
 Пример разумного исключения:
-Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в т.ч. в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7.
+Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7.
 == Взаимодействие с другими репозиториями ==
-Если делаются не бэкпорты пакетов из Sisyphus, а существенные доработки или обновления - следует уведомить майнтейнера пакета в нём и сотрудничать с ним для сохранения добавленной функциональности.
+Если делаются не бэкпорты пакетов из Sisyphus, а существенные доработки или обновления — следует уведомить майнтейнера пакета в нём и сотрудничать с ним для сохранения добавленной функциональности.
-Если в Sisyphus такого пакета попросту нет - желательно анонсировать сборку не только в backports@, но и в sisyphus@ (возможно, через кого-либо иного, подписанного на этот список рассылки).
+Если в Sisyphus такого пакета попросту нет — желательно анонсировать сборку не только в backports@, но и в sisyphus@ (возможно, через кого-либо иного, подписанного на этот список рассылки).
 == Библиотеки и всё что с ними связано ==
 Пакеты с библиотеками, входящими в пакетную базу дистрибутива, реализуют множество интерфейсов, которые определяют бинарную совместимость дистрибутива.
-Бэкпорт новой версии библиотеки, входящей в состав дистрибутива, может нарушить бинарную совместимость дистрибутива. Это приведет к необходимости пересборки некоторого множества входящих в дистрибутив пакетов. Этого допускать нельзя.
+Бэкпорт новой версии библиотеки, входящей в состав дистрибутива, может нарушить бинарную совместимость дистрибутива. Это приведет к необходимости пересборки некоторого множества входящих в дистрибутив пакетов. Такое бэкпортирование допускается, только если будет осуществлена пересборка всех зависимых пакетов.
+-->
-Таким образом, бэкпорты должны ограничиваться точечными изменениями входящих в дистрибутив библиотек, не приводящими к несовместимости с updates и/или необходимости пересборки в backports программ,  которые слинкованы с предыдущими версиями библиотек.
-Попросту говоря, soname changes prohibited.
+{{Category navigation|title=Backports|category=Backports}}
+{{Category navigation|title=Черновики нормативных документов|category=Черновики нормативных документов|sortkey={{SUBPAGENAME}}}}