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-update-tag.

Архив с немодифицированным исходным кодом и отдельными патчами

Если дерево с немодифицированным исходным кодом хранится в отдельном подкаталоге, а локальные изменения хранятся в gear-репозитории в виде отдельных патч-файлов, то правила экспорта могут выглядеть следующим образом:

tar: package_name
copy: *.patch

Такое устройство репозитория получается при использовании утилиты gear-srpmimport, предназначенной для быстрой миграции от srpm-файла к gear-репозиторию.

Смешанные типы

Вышеперечисленные типы устройства gear-репозитория являются основными, но не исчерпывающими. Правила экспорта достаточно выразительны для того, чтобы реализовать всевозможные сочетания основных типов и создать полнофункциональный gear-репозиторий на любой вкус.