Gear (Get Every Archive from git package Repository) — система для работы с произвольными архивами программ. В качестве хранилища данных gear использует git, что позволяет работать с полной историей проекта.
Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также в минимизации используемого дискового пространства для хранения архива репозитория за длительный срок и минимизации трафика при обновлении исходного кода.
Идея gear заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно sed и git) можно было бы собирать пакеты из произвольно устроенного git-репозитория, по аналогии с hasher, который был задуман как средство для сборки пакетов из произвольных «srpm-пакетов».
7.1. Структура репозитория
Хотя 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-файл самого пакета.
