Знакомство со схемой упаковки pam-pkcs11

На примере pam_pkcs11 познакомимся с одной довольно удобной схемой организации gear-репозитория.

Удобства такой схемы:

• Подходит для pull-request-ов к upstream-ному проекту.
• Поддерживается дисциплина, при которой ясно (читающему и любому новому мейнтейнеру) актуальное состояние набора патчей и актуальный вид каждого патча (а не так, что исходное изменение утонуло глубоко в историю -- но этого мало -- ещё и претерпевало изменение во время мёрджей с апстримом, при этом актуальность изначальной задумки и правильность результата никому непонятна, кроме, возможно, тех, кто делал мёрджи).

Неудобства такой схемы:

• Много merg-ей. (Но это только для мейнтейнера пакета, а не в потенциальных pull-request-ах.)
• Длинные .gear/rules. (Но это необязательно считать явным неудобством, т.к. там каждая запись на самом деле осмысленна, по делу, выражает имеющиеся патчи, и прочитать .gear/rules достаточно, чтобы понять, какие сделаны патчи.)
• Сложные .gear/rules в случае взаимозависимых патчей.

Когда я брался за чужой незнакомый пакет с утонувшими патчами, иногда было ничего непонятно в мешанине кода. Переделка (довольно трудоёмкая на начальном этапе взятия чужого пакета) в такую схему приводит к большей ясности для себя и других.

Основа схемы. Апстримный тег с версией

Схема такая.

Есть тег, соответствующий апстримной версии. От него ответвляются ветки (на разные темы) с нашими изменениями. И так в общем случае для каждой апстримной версии; это отражено в именах веток с патчами: в их именах присутствует апстримная версия.

Соотвествие между ветками и файлами с патчами

Получается, что имена веток с патчами соответствуют именам самих файлов с патчами, которые в ALT Packaging HOWTO рекомендуется давать со включением базовой апстримной версии. Т.е. соответствие очень простое.

Сюда же укладывается возможное "отклонение" от общего случая: Вы бы не стали специально переделывать файл с патчем, если он прикладывается к новой версии апстрима. В имени файла осталась бы старая версия. Так же менять соответствующее diff-правило в .gear/rules и обновлять сохранённые теги в .gear/tags не надо в таком случае (поэтому оно пишется без использования переменной @version@, а явным прописыванием базовой версии).

Однако, принцип, что патч не переделывается без необходимости, может вступать в противоречие с другим желанием мейнтейнера пакета: иметь смёрдженные пачти и исходники в одном каком-то коммите. Над этим надо подумать (что кому удобнее).