Backports policy

Статус	Черновик, обсуждение не начато
Автор(ы)	Михаил Шигорин
Контрибутор(ы)	Алексей Боровской, Sir Raorn
Обязательно в
Метабаг	не создан

Этот документ регламентирует назначение репозитория бэкпортов, его структуру, порядок помещения пакетов в репозиторий, а также требования, которым должен соответствовать пакет.

Обновление policy

Backports policy сопровождается и обновляется участниками backports maintainers committee.

Состав backports maintainers committee:
– “Michael Shigorin”
– «Alexey I. Froloff (Sir Raorn)"

1. Назначение репозитория
–

Репозиторий предназначен для хранения портированных на соответствующее
семейство дистрибутив пакетов. Для каждого семейства дистрибутивов создается
отдельный репозиторий. В настоящее время (лето 2007) существуют репозитории
для следующих дистрибутивов:

– 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 (только архив).

2. Структура репозитория
–

Каждый репозиторий создается с помощью утилиты genbasedir. Поддерживаемые
архитектуры — i586 и i686. Для каждой из архитектур определена компонента
backports. При необходимости в репозиторий могут быть добавлены другие архитектуры.

2.1. Расположение репозитория и доступ к нему

Получить доступ к репозиторию на чтение можно несколькими способами:

– По протоколу ftp

ftp://ftp.altlinux.org/pub/distributions/ALTLinux/backports/

– По протоколу rsync

2.2. Помещение пакетов в репозиторий

Для получения возможности выкладывать пакеты в репозиторий необходимо быть
участником команды разработчиков ALT Linux. Если вы уже в команде, ничего
дополнительного не требуется. Новых участников команды ждут по адресу join at
altlinux dot ru.

Пакеты следует выкладывать на cvs.altlinux.org в один из следующих каталогов:

– для ALT Linux 2.3 и выше:

– для ALT Linux 2.2 Master сборка backports прекращена.

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

3. Требования к пакетам
–

3.1. Пакеты должны собираться в среде hasher или sandman с подключенными репозиториями:

– Основной репозиторий дистрибутива. Например, репозиторий с дистрибутивом

– Репозиторий с updates для дистрибутива.

– Репозиторий с backports для дистрибутива.

Использование hasher предпочтительнее. На системах старее ветки 2.3 возможно
использовать только sandman, поскольку hasher на них ещё не портирован.

3.2. Работа со спеком

– Поле Packager не должно изменяться. Всю необходимую информацию заностить в changelog.

• Sat Sep 25 2004 Alexey Borovskoy 0.4-alt0.M24.1
• Backport to Master 2.4
• 0.4

– Build Requires? должен быть адаптирован под платформу, на которую производится портирование.

3.3. Правила нумерации релизов

Релизы нумеруются следующим образом: BRANCH_POINT_RELEASE.BRANCH.REVISION.
Таким образом, полное наименование пакета будет таким:

%name-%version-BRANCH_POINT_RELEASE.BRANCH.REVISION.

Где:

– REVISION – номер ревизии пакета внутри репозитория backports. Нумерация начинается с 1.

– BRANCH_POINT_RELEASE – строка, описывающая релиз, из которого «растет» данная ветка;

– BRANCH – версия ветки. Допустимые значения:

и по аналогии для веток новее 4.0.

При обновлении до новой версии (%version) пакета, REVISION сбрасывается в 1 и
BRANCH_POINT_RELEASE устанавливается в “alt0”.

Обоснование:

Новая версия пакета, собираемого в backports, должна иметь номер релиза
меньший, чем та же версия в Сизифе, но при этом не меньший, чем та же версия в
backports для предыдущих серий.

Пример разумного исключения:

Если необходимо предотвратить возможность обновления с релиза вида
alt0.BRANCH.REVISION до сизифовского alt7 при наличии в Сизифе alt8
(в т.ч. в случае серьёзной ошибки, исправленной в alt8), можно сделать
релиз вида alt7.BRANCH.REVISION, при условии что за основу взят именно
alt8 а не alt7.

4. Взаимодействие с другими репозиториями
–

Если делаются не бэкпорты пакетов из Sisyphus, а существенные
доработки или обновления – следует уведомить майнтейнера пакета
в нём и сотрудничать с ним для сохранения добавленной
функциональности.

Если в Sisyphus такого пакета попросту нет – желательно
анонсировать сборку не только в backports@, но и в sisyphus@
(возможно, через кого-либо иного, подписанного на этот список
рассылки).

5. Библиотеки и всё что с ними связано
–

Пакеты с библиотеками, входящими в пакетную базу дистрибутива,
реализуют множество интерфейсов, которые определяют бинарную
совместимость дистрибутива.

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

Таким образом, бэкпорты должны ограничиваться точечными изменениями
входящих в дистрибутив библиотек, не приводящими к несовместимости
с updates и/или необходимости пересборки в backports программ,
которые слинкованы с предыдущими версиями библиотек.

Попросту говоря, soname changes prohibited.

Changelog:
2007–06–18/19 (mike):
изменён отвечающий за backports (s/aris/mike/g);
обновлены версионно-зависимые формулировки;
убраны рекомендации касательно Master 2.2 (уже не поддерживается по техническим причинам);
[NMU]
Добавлен пункт 5