Gear/tags
Пример использования .gear/tags
Цель использования gear tags — получить в .src.rpm-е тарбол оригинальных сырцов + кумулятивный патч наших изменений.
Структура репозитория должна быть примерно такой:
- upstream — сюда импортятся оригинальные тарболы один за другим, при этом проставляются таги с именем «vверсия», то есть v1.0, v2.0, v3.0 и т.д
- master — это наш рабочий бранч, тут мы храним спек, дополнительные sources и изменённые исходники. На каждый релиз пакета проставляются таги вида %version-%release, то есть 1.0-alt1, 1.0-alt2, 1.0-alt3 и т. д.
master и upstream связаны следующим образом: когда-то, сразу после прикладывания патчей (версия нашего проекта foo совпадает в master и upstream) для создания общего base, в бранче master был выполнен
git merge -s ours upstream
В дальнейшем, при обновлении версии, производится
git merge upstream
При этом все наши интегрированные патчи, спек, sources — сохраняются. Если возникает конфликт, git об этом напишет, остаётся лишь устранить его (например, воспользовавшись git mergetool).
Для реализации поставленной задачи необходимо несколько вникнуть в применение директив файла .gear/rules, и соответствующим образом его модифицировать. Найти информацию можно в заголовке /usr/bin/gear или в man-странице gear-rules(5)
Итак, нам необходимо, чтобы в тарбол помещалось оригинальное дерево исходников:
tar: v@version@:foo
В данном случае мы говорим, что в tar-файл необходимо завернуть директорию foo, которая должна быть взята из тага v@version@. Так же можно использовать не таг, а непосредственно идентификатор коммита (sha1 хэш). @version@ — это тот тег Version:, что прописан в спеке.
Теперь нужно сделать кумулятивный diff:
diff: v@version@:foo foo
Здесь тоже всё просто — делается diff между директорией foo тага v@version@ и директорий foo из текущего бранча (master). Имя diff-а по умолчанию %name-%version-%release.patch. Разумеется, название diff-а в спеке должно указывать на правильный patch-файл.
Осталось сформировать файл с состоянием тэгов на текущий момент времени (этот файл в дальнейшем позволит пересобирать пакет вне зависимости от того, куда и как были переставлены тэги, упоминаемые в файле .gear/rules). Для этого предназначена специальная утилита gear-update-tag(1)
gear-update-tag -ac
И не забыть закоммитить:
git commit -a -m 'Switched to use .gear/tags'
Накладываемые ограничения
Ограничения, накладываемые на ссылки на другие коммиты, необходимы для того, чтобы репозиторий, содержащий основной коммит, содержал всё, что требуется для однозначного извлечения исходного кода.
В частности, если в коммите C вы ссылаетесь на некоторый коммит с помощью .gear/rules, то необходимо, чтобы этот коммит был среди предков коммита C -- тогда git обеспечит обязательное присутствие коммита в репозитории до тех пор, пока в нём находится коммит C.
Идея, лежащая в основе ограничения, простая: необходимо обеспечить, чтобы всякий раз из коммита C собиралось одно и то же.