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

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

Зачем такая схема gear-репозитория?

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

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

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

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

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

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

Схема такая.

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

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

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

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

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

Знакомство со схемой упаковки pam_pkcs11

[imz@ovicaa TMP]$ git clone git://git.altlinux.org/gears/p/pam_pkcs11.git
[imz@ovicaa TMP]$ cd pam_pkcs11/

git tag; git branch -a

Посмотрим какие там есть теги и бранчи:

[imz@ovicaa pam_pkcs11]$ git tag
0.6.1-alt1
0.6.1-alt2
0.6.1-alt3
0.6.1-alt4
0.6.1-alt5
0.6.4-alt1
0.6.4-alt1.1
0.6.4-alt1.M60P.1
0.6.4-alt1.M60T.1
0.6.4-alt2
0.6.8-alt0.git20140828.M70C.1
0.6.8-alt1.git20140828
0.6.8.0.48-alt1
0.6.9-alt0.M70C.1
0.6.9-alt0.M80P.1
0.6.9-alt1
0.6.9-alt1.M70T.1
0.6.9-alt2
0.6.9-alt2.M70T.0.M70C.1
0.6.9-alt2.M70T.1
0.6.9-alt2.M80P.1
0.6.9-alt3

-- это сборочные теги, которые создал мейнтенер пакета для сборок очередных релизов пакета в репозитории пакетов ALT;

gb-c7-task169526.200
gb-c7-task172681.100
gb-p6-task172398.100
gb-p8-task171625.200
gb-p8-task173707.200
gb-sisyphus-task130048.100
gb-sisyphus-task171630.100
gb-sisyphus-task172550.200
gb-sisyphus-task172679.100
gb-sisyphus-task75437
gb-t6-task172356.200
gb-t7-task172416.200
gb-t7-task172538.200

-- эти теги проставила сама сборочница по завершении заданий на сборку, чтобы отметить, какие коммиты/теги успешно привели к помещению нового пакета в репозитории пакетов ALT;

imz/0.6.1-alt1
imz/0.6.1-alt2
imz/0.6.1-alt3
imz/0.6.1-alt4
imz/0.6.1-alt5
imz/0.6.4-alt1.1
imz/0.6.4-alt2

-- это тоже сборочные теги (на их имена нет никаких ограничений), которые создал мейнтенер пакета для сборок очередных релизов пакета в репозитории пакетов ALT или с подобными целями;

pam_pkcs11-0.6.1
pam_pkcs11-0.6.2
pam_pkcs11-0.6.3
pam_pkcs11-0.6.4
pam_pkcs11-0.6.7
pam_pkcs11-0.6.8

-- эти теги отмечали апстримные версии (в чистом виде).

[imz@ovicaa pam_pkcs11]$ git branch -a
* sisyphus
  remotes/origin/5.1
  remotes/origin/HEAD -> origin/sisyphus
  remotes/origin/c7
  remotes/origin/p6
  remotes/origin/p7
  remotes/origin/p8
  remotes/origin/sisyphus
  remotes/origin/t6
  remotes/origin/t7
[imz@ovicaa pam_pkcs11]$ 

Эти ветки представляют историю пакета в каждом из репозиториев пакетов ALT. При клонировании нашей рабочей веткой стала sisyphus; она сейчас checked out.

gear-restore-tags

В .gear/tags сохранены теги/ссылки-бранчи, которые участвовали в правилах .gear/rules при последней сборке в Sisyphus (у нас же эта ветка сейчас checked out). (Git использовался мейнтейнером как способ описать, что откуда брать, путём именования коммитов и использования этих имён в .gear/rules. После того, как эти "именованые ссылки" были сохранены в файле, их можно и стереть из репозитория Git без потери информации.)

Тут можно отметить важный принцип gear: Благодаря этому вся информация, нужная для повторения сборки, сохранена внутри "сборочного" коммита (.gear/tags и история Git со всеми предками). (В случае specsubst нужно уточнить: "внутри сборочного тега".) Это не зависит от того, скопировал ли человек чужие теги. (Теги всё-таки во многом дело более индивидуальное, и их не обязаны все копировать и распространять.)

Восстановим их и познакомимся:

[imz@ovicaa pam_pkcs11]$ gear-restore-tags
[imz@ovicaa pam_pkcs11]$ git tag
...

...тут новых не появилось;

...
[imz@ovicaa pam_pkcs11]$ git branch -a
  pam_pkcs11-0.6.9
  pam_pkcs11-0.6.9-alt-build
  pam_pkcs11-0.6.9-ask-pin-later
  pam_pkcs11-0.6.9-ask-pin-later-with-option-ask_pin
  pam_pkcs11-0.6.9-buffer
  pam_pkcs11-0.6.9-docs
  pam_pkcs11-0.6.9-option-global_ca
  pam_pkcs11-0.6.9-ru.po

-- а вот это новые, для сборки (вызывает некоторое непонимание наличие ветки pam_pkcs11-0.6.9, а не тега; TODO: разобраться, откуда взялось!); эти неновые, были после клонирования:

* sisyphus
  remotes/origin/5.1
  remotes/origin/HEAD -> origin/sisyphus
  remotes/origin/c7
  remotes/origin/p6
  remotes/origin/p7
  remotes/origin/p8
  remotes/origin/sisyphus
  remotes/origin/t6
  remotes/origin/t7
[imz@ovicaa pam_pkcs11]$

Пример добавления ещё одного патча в сборку

Делаем наши изменения

[imz@ovicaa pam_pkcs11]$ git checkout -b pam_pkcs11-0.6.9-my-changes pam_pkcs11-0.6.9
Switched to a new branch 'pam_pkcs11-0.6.9-my-changes'
[imz@ovicaa pam_pkcs11]$ echo '/* My changes. */' >>src/pam_pkcs11/pam_config.h 
[imz@ovicaa pam_pkcs11]$ git --no-pager diff
diff --git a/src/pam_pkcs11/pam_config.h b/src/pam_pkcs11/pam_config.h
index cf4e089..8096ff6 100644
--- a/src/pam_pkcs11/pam_config.h
+++ b/src/pam_pkcs11/pam_config.h
@@ -51,3 +51,4 @@ struct configuration_st {
 struct configuration_st *pk_configure( int argc, const char **argv );
 
 #endif
+/* My changes. */
[imz@ovicaa pam_pkcs11]$ git commit -a -m 'My changes'
[pam_pkcs11-0.6.9-my-changes 3285e31] My changes
 1 file changed, 1 insertion(+)
[imz@ovicaa pam_pkcs11]$ 

Подшиваем коммиты с нашими изменениями в историю сборочной ветки

Главное, чтобы коммит оказался в истории "сборочного" тега, а как будет сделан merge, конечно, неважно для gear; важно, что мы сможем сослаться на него в .gear/rules.

Это дело предпочтений мейнтейнеров, но не требования. Возможны разные варианты (как добиться, чтобы коммит был в истории).