директива: параметры
Основной смысл хранения исходного кода пакетов в 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 релизного 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-репозитория следующим образом:
С помощью простого правила
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-репозиторий на любой вкус.