Abstract
Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также в минимизации используемого дискового пространства для хранения архива репозитория за длительный срок и минимизации трафика при обновлении исходного кода.
Идея
gear(1)
заключается в том, чтобы с помощью одного файла с простыми правилами
(для обработки которых достаточно sed
и git
) можно было бы собирать
пакеты из произвольно устроенного git-репозитория, по аналогии с
hasher(7)
, который
был задуман как средство собирать пакеты из произвольных srpm-пакетов.
Структура репозитория
Хотя gear и не накладывает ограничений на внутреннюю организацию git-репозитория (не считая требования наличия файла с правилами), есть несколько соображений о том, как более эффективно и удобно организовывать git-репозитории, предназначенные для хранения исходного кода пакетов.
Одна сущность — один репозиторий
Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок.
-
Плюсы: Соблюдение этого правила облегчает совместную работу над пакетом, поскольку не перегруженный репозиторий легче клонировать и в целом инструментарий
git
больше подходит для работы с такими репозиториями. -
Минусы: Несколько сложнее выполнять операции fetch и push в случае, когда репозиториев, которые надо обработать, много. Впрочем, fetch/push в цикле выручает.
Несжатый исходный код
Сжатый разными средствами (gzip
, bzip2
и т.п.) исходный код лучше
хранить в git-репозитории в несжатом виде.
-
Плюсы: Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (
git diff
). Посколькуgit
хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколуgit
, более эффективен на несжатых данных. -
Минусы: Поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода.
Распакованный исходный код
Исходный код, запакованный архиваторами (tar
, cpio
, zip
и т.п.),
лучше хранить в git-репозитории в распакованном виде.
-
Плюсы: Существенно удобнее вносить изменения в конечные файлы и отслеживать изменения в них, заметно меньше трафик при обновлении.
-
Минусы: Поскольку
git
из информации о владельце, правах доступа и дате модификации файлов хранит только исполняемость файлов, любой архив, созданный из репозитория, будет по этим параметрам отличаться от первозданного. Помимо потери нативности, изменение прав доступа и даты модификации может теоретически повлиять на результат сборки пакета. Впрочем, сборку таких пакетов, если они будут обнаружены, всё равно придётся исправить.
Форматированный changelog
В changelog релизного commit’а имеет смысл включать соответствующий
текст из changelog’а пакета, как это делают утилиты gear-commit
(обёртка к git commit
, специально предназначенная для этих целей) и
gear-srpmimport
. В результате можно будет получить представление об
изменениях в очередном релизе пакета, не заглядывая в spec-файл самого
пакета.
Правила экспорта
С одной стороны, для того, чтобы srpm-пакет мог быть импортирован в git-репозиторий наиболее удобным для пользователя способом, язык правил, согласно которым производится экспорт из коммита репозитория (в форму, из которой можно однозначно изготовить srpm-пакет или запустить сборку), должен быть достаточно выразительным.
С другой стороны, для того, чтобы можно было относительно безбоязненно собирать пакеты из чужих gear-репозиториев, этот язык правил должен быть достаточно простым.
Файл правил экспорта (по умолчанию .gear/rules
) состоит из строк формата
директива: параметры
параметры разделяются пробельными символами.
Директивы позволяют экспортировать: - любой файл из дерева, соответствующего коммиту; - любой каталог из дерева, соответствующего коммиту в виде tar- или zip-архива; - unified diff между любыми каталогами, соответствующими коммитам.
Файлы на выходе могут быть сжаты разными средствами (gzip
, bzip2
и т.п.).
В качестве коммита может быть указан как целевой коммит (значение параметра
-t
утилиты gear
, так и любой из его предков при соблюдении условий,
гарантирующих однозначное вычисление полного имени коммита-предка по целевому
коммиту.
Правила экспорта из gear-репозитория описаны детально в
gear-rules(5)
.
Основные типы устройства gear-репозитория
Правила экспорта реализуют основные типы устройства gear-репозитория следующим образом:
Архив с модифицированным исходным кодом
С помощью простого правила
tar: .
всё дерево исходного кода экспортируется в один tar-архив. Если у проекта есть upstream, публикующий tar-архивы, то добавление релиза в имя tar-архива, например, с помощью правила
tar: . name=@name@-@version@-@release@
позволяет избежать коллизий.
Архив с немодифицированным исходным кодом и патчем, содержащем локальные изменения
С помощью двух правил,
tar: v@version@:.
diff: v@version@:. .
можно экспортировать всё дерево исходного кода в виде tar-архива
с немодифицированным исходным кодом, помеченным тэгом v@version@
,
и патча, который нужно приложить к дереву с немодифицированным кодом
для того, чтобы получить дерево с исходным кодом. Тэг v@version@
должен быть зарегистрирован с помощью утилиты gear-store-tags
.
Архив с немодифицированным исходным кодом и отдельными патчами
Если дерево с немодифицированным исходным кодом хранится в отдельном подкаталоге, а локальные изменения хранятся в gear-репозитории в виде отдельных патч-файлов, то правила экспорта могут выглядеть следующим образом:
tar: package_name
copy: *.patch
Такое устройство репозитория получается при использовании утилиты
gear-srpmimport
, предназначенной для быстрой миграции от srpm-файла
к gear-репозиторию.
Смешанные типы
Вышеперечисленные типы устройства gear-репозитория являются основными, но не исчерпывающими. Правила экспорта достаточно выразительны для того, чтобы реализовать всевозможные сочетания основных типов и создать полнофункциональный gear-репозиторий на любой вкус.