Backports Policy: различия между версиями
м (metadata) |
(→Сборка) |
||
| (не показана 21 промежуточная версия 8 участников) | |||
| Строка 1: | Строка 1: | ||
{{DraftPolicy | {{DraftPolicy | ||
|responsible= | |responsible=cas@, glebfm@, george@, mike@ | ||
|discussion_link= | |discussion_link=https://lore.altlinux.org/devel/YQFM7vFVjISyQLV7@glebfm.cloud.tilaa.com/T/#u | ||
|discussion_since= | |discussion_since=2021 | ||
}} | }} | ||
== Backports policy == | == Backports policy == | ||
Этот документ регламентирует | Этот документ регламентирует правила оформления, сборки и публикации пакетов в [[Branches|стабильные репозитории]] ALT Linux Team. | ||
<!-- | |||
{{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» не срабатывает — здесь поможет только здравый смысл. | |||
** (возможно, здравый смысл стоило проявить ранее, и в исходном пакете добавить .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|общим правилам]]. | |||
== Сборка == | |||
* Сборка пакета в стабильный репозиторий отличается только указанием названия репозитория в [[Справочник_по_git.alt|командах сборочницы]]. | |||
* Как правило, права на сборку в стабильный репозиторий есть не у всех членов Team, и соответствующее успешное задание должно быть одобрено командой, сопровождающей конкретный репозиторий (например, сначала пройти тестирование). | |||
** Текущая [[Branches/p11#Процедура_сборки_пакетов_Одиннадцатой_платформы|Процедура_сборки_пакетов_Одиннадцатой_платформы]] | |||
<!-- | |||
== Структура репозитория == | == Структура репозитория == | ||
Каждый репозиторий создается с помощью утилиты <tt>genbasedir</tt>. Поддерживаемые архитектуры — i586 и i686. Для каждой из архитектур определена компонента <tt>backports</tt>. При необходимости в репозиторий могут быть добавлены другие архитектуры. | Каждый репозиторий создается с помощью утилиты <tt>genbasedir</tt>. Поддерживаемые архитектуры — i586 и i686. Для каждой из архитектур определена компонента <tt>backports</tt>. При необходимости в репозиторий могут быть добавлены другие архитектуры. | ||
| Строка 29: | Строка 63: | ||
== Помещение пакетов в репозиторий == | == Помещение пакетов в репозиторий == | ||
По состоянию на 2010 год централизованная сборка backports силами mike@ прекращена. | |||
Для получения возможности выкладывать пакеты в репозиторий необходимо быть участником команды разработчиков ALT Linux. Если вы уже в команде, ничего | Для получения возможности выкладывать пакеты в репозиторий необходимо быть участником команды разработчиков ALT Linux. Если вы уже в команде, ничего | ||
дополнительного не требуется. Информация по присоединению к команде находится [[Join|здесь]]. | дополнительного не требуется. Информация по присоединению к команде находится [[Join|здесь]]. | ||
Пакеты следует выкладывать на devel.altlinux.org в один из следующих каталогов: | Пакеты следует выкладывать на devel.altlinux.org в один из следующих каталогов: | ||
* для ALT Linux 2.4 и выше: /incoming/backports/2.4/ | * для ALT Linux 2.4 и выше: /incoming/backports/2.4/ и т. п.; ответственный за сборку — mike@ | ||
* для ALT Linux 2.2 Master и ALT Linux 2.3 Compact, Junior сборка backports прекращена. | * для ALT Linux 2.2 Master и ALT Linux 2.3 Compact, Junior сборка backports прекращена. | ||
| Строка 48: | Строка 83: | ||
=== Исправления spec-файла === | === Исправления spec-файла === | ||
Поле Packager не должно изменяться. Всю необходимую информацию | Поле Packager не должно изменяться. Всю необходимую информацию нужно заносить в changelog. | ||
Например: | Например: | ||
| Строка 59: | Строка 94: | ||
Поле BuildRequires должно быть адаптировано под дистрибутив, на который производится портирование. | Поле BuildRequires должно быть адаптировано под дистрибутив, на который производится портирование. | ||
В [[etersoft-build-utils]] предусмотрена команда вида <code>rpmbp -b p8</code>, | |||
которая выполняет необходимые преобразования спека: релиза пакета, ChangeLog, BuildRequires, Requires. | |||
=== Правила нумерации релизов === | === Правила нумерации релизов === | ||
| Строка 66: | Строка 104: | ||
Где: | Где: | ||
* | * ADAPTED_RELEASE — релиз, выбраный таким образом, что ORIG_RELEASE <= ADAPTED_RELEASE < SISYPHUS_RELEASE. | ||
: Рекомендуемое | : Рекомендуемое значение — SISYPHUS_RELEASE - 1. | ||
* | * ORIG_RELEASE — строка, описывающая релиз пакета, из которого «растёт» данная ветка (который был переложен в бранч из Сизифа); | ||
* | * SISYPHUS_RELEASE — релиз пакета в Сизифе, на базе которого делался backport пакет; | ||
* | * BACKPORT_RELEASE — номер релиза пакета внутри репозитория backports. Нумерация начинается с 1. | ||
* | * DISTRO — репозиторий ([[Branches|бранч]]) либо дистрибутив (до ALM2.4 включительно), на который осуществляется портирование. Допустимые значения: | ||
** | ** 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; | |||
и по аналогии для веток | и по аналогии для более новых веток. | ||
При обновлении в бэкпортах до новой версии (%version) пакета, BACKPORTS_RELEASE сбрасывается в 1 и ORIG_RELEASE устанавливается в <tt>alt0</tt>. | При обновлении в бэкпортах до новой версии (%version) пакета, BACKPORTS_RELEASE сбрасывается в 1 и ORIG_RELEASE устанавливается в <tt>alt0</tt>. | ||
| Строка 88: | Строка 135: | ||
Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7. | Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7. | ||
== Взаимодействие с другими репозиториями == | == Взаимодействие с другими репозиториями == | ||
Если делаются не бэкпорты пакетов из Sisyphus, а существенные доработки или обновления — следует уведомить майнтейнера пакета в нём и сотрудничать с ним для сохранения добавленной функциональности. | Если делаются не бэкпорты пакетов из Sisyphus, а существенные доработки или обновления — следует уведомить майнтейнера пакета в нём и сотрудничать с ним для сохранения добавленной функциональности. | ||
| Строка 98: | Строка 144: | ||
Бэкпорт новой версии библиотеки, входящей в состав дистрибутива, может нарушить бинарную совместимость дистрибутива. Это приведет к необходимости пересборки некоторого множества входящих в дистрибутив пакетов. Такое бэкпортирование допускается, только если будет осуществлена пересборка всех зависимых пакетов. | Бэкпорт новой версии библиотеки, входящей в состав дистрибутива, может нарушить бинарную совместимость дистрибутива. Это приведет к необходимости пересборки некоторого множества входящих в дистрибутив пакетов. Такое бэкпортирование допускается, только если будет осуществлена пересборка всех зависимых пакетов. | ||
--> | |||
{{Category navigation|title=Backports|category=Backports}} | {{Category navigation|title=Backports|category=Backports}} | ||
{{Category navigation|title=Черновики нормативных документов|category=Черновики нормативных документов|sortkey={{SUBPAGENAME}}}} | |||
Текущая версия от 14:41, 6 декабря 2024
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, и соответствующее успешное задание должно быть одобрено командой, сопровождающей конкретный репозиторий (например, сначала пройти тестирование).