⁠Глава 7. Инструмент GEAR

Gear (Get Every Archive from git package Repository) — система для работы с произвольными архивами программ. В качестве хранилища данных gear использует git, что позволяет работать с полной историей проекта.

Gear поддерживает полный цикл организации репозиториев:

создание репозитория или импорт существующих src.rpm-пакетов;
обновление upstream-кода в репозиториях;
наложение патчей и пакетирование;
экспорт pkg.tar и src.rpm, сборка бинарных RPM-пакетов.

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

Идея gear заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно sed и git) можно было собирать пакеты из произвольно устроенного git-репозитория, по аналогии с hasher, который был задуман как средство для сборки пакетов из произвольных SRPM-пакетов.

⁠7.1. Структура репозитория

Хотя gear не накладывает ограничений на внутреннюю организацию git-репозитория (за исключением требования наличия файла с правилами), существуют рекомендации, позволяющие сделать работу более эффективной и удобной.

⁠

Одна сущность—один репозиторий

Не следует помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок.

Плюсы: соблюдение этого правила облегчает совместную работу над пакетом, поскольку неперегруженный репозиторий легче клонировать, а инструменты git лучше подходят для работы с такими репозиториями.
Минусы: несколько сложнее выполнять операции fetch и push, если репозиториев, которые надо обработать, много. Впрочем, выполнение fetch/push в цикле решает эту проблему.

⁠

Несжатый исходный код

Исходный код, сжатый различными средствами (gzip, bzip2 и т.п.), рекомендуется хранить в git-репозитории в несжатом виде.

Плюсы:
- изменения удобнее отслеживать средствами git (git diff;
- git сам хранит объекты в сжатом виде, поэтому двойное сжатие редко даёт выигрыш;
- алгоритмы передачи данных git эффективнее работают с несжатыми данными.
Минусы: может снижаться «нативность» исходного кода (из-за различий в способах сжатия).

⁠

Распакованный исходный код

Исходный код, упакованный архиваторами (tar, cpio, zip и т.п.), рекомендуется хранить в git-репозитории в распакованном виде.

Плюсы:
- существенно проще вносить изменения в конечные файлы и отслеживать их;
- уменьшается объём передаваемых данных при обновлении.
Минусы:
- Git не сохраняет владельца, права доступа (кроме исполняемости) и время модификации;
- архив, собранный из репозитория, может отличаться от оригинала;
- в редких случаях это может повлиять на результат сборки.

⁠

Форматированный changelog

В changelog релизного коммита рекомендуется включать соответствующий текст из changelog пакета. Это делают утилиты gear-commit (обёртка к git commit, специально предназначенная для этих целей) и gear-srpmimport. Такой подход позволяет видеть изменения в очередном релизе пакета, не открывая в spec-файл.