Gear/old

Использование gear/git

Дополнительные статьи:

Пример работы с gear-tags

gear — инструмент, позволяющий использовать git для хранения исходных пакетов.

Что нужно:

• установить gear: apt-get install gear;
• дополнительно можно установить cogito - более дружественный интерфейс к git, в дальнейшем некоторые команды будут описываться из пакета cogito.

Как работает gear

Gear - инструмент, позволяющий, оперируя данными из git-репозитория, проводить сборку исходного текста в rpm-пакет,тарболл или просто экспортировать результаты выполнения правил (gear-rules) в определённый каталог.

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

Так как gear берёт все данные исключительно из git-репозитория и пользуется для этого исключительно набором утилит git, то все изменения должны быть в обязательном порядке внесены в репозиторий командой git-commit -a. Иначе gear будет работать с предыдущими данными, и все последние изменения использоваться при сборке не станут. Но для тестирования некоторых коммитов у gear есть замечательная опция --commit, позволяющая выполнить так называемый временный коммит всех текущих изменений и использовать его исключительно для сборки, откатив в дальнейшем. Но даже с этой опцией безусловно предварительно нужно выполнить git-add для всех новых файлов и git-rm для всех файлов, подлежащих удалению.

gear позволяет собирать пакет как с помощью обычного системного rpm в системном окружении, так и с помощью hasher в создаваемом с нуля чруте. Преимущества использования gear для мантейнера вполне очевидны:

• Возможность использования в процессе сборки и разработки пакета всех достоинств репозитория git, основное из которых - хранение истории всех изменений плюс ведение нескольких веток.
• Унифицированный механизм сборки и публикации исходных текстов пакета.
• Удобный интерфейс с rpm и hasher.
• Возможность (теоретическая, я не знаю практических примеров), сборки из одного репозитория пакета для разных дистрибутивов Linux
• Значительная экономия трафика при выкладывании и получении обновлений уже загруженных ранее git-репозиториев.
• Возможность ведения нескольких веток одного проекта разными разработчикам, с дальнейшей процедурой объединения изменений.

Говоря о преимуществах, не стоит забывать и про недостатки, самым основным из которых я вижу невозможность получения только последней версии git-репозитория, исключая необходимость загружать к себе всю историю ведения пакета. Наличие такой возможности позволило бы значительно экономить сетевой трафик. Для примера, git-репозиторий ядра в ALT Linux - это порядка 100 мегабайт. И это всё нужно выкачать любому, кто захочет из gear собрать свежее ядро. Загрузка же только последней ревизии git-репозитория ядра должна была бы весить около 30 мегабайт. Разница ощутима, и она будет расти по мере внесения изменений в git-репозиторий.

Импорт пакетов:

Итак, какие действия нужно выполнить для начала работы с gear/git ? Первое - это import существующего пакета (или загрузка его с публичного git-репозитория). Для импорта необходимо выполнить следующие действия:

mkdir <имя-пакета>
cd <имя-пакета>
git init
gear-srpmimport <srpm-пакеты>

После того, как в текущем каталоге создан git-репозиторий, содержащий исходный код пакетов, рекомендуется пройтись по автоматически созданному во время импорта файлу .gear-rules.

Из замен: все copy:<файл> рекомендуется заменять на маску. Например так:

copy?: *.patch *.diff
copy: <имя программы>-*.tar

впрочем, gear-srpmimport обычно делает эту работу за вас. Один реальный лог импорта

Синтаксис .gear-rules

Самое свежее описание синтаксиса можно найти в gear-rules(5), входящей в состав пакета gear.

Файл с правилами, описывающими поведение gear при сборке пакетов, должен содержать строки в следующем формате: директива: аргументы...

Все пустые строки, а также строки , начинающиеся с # - игнорируются

Доступные директивы: spec, tags, copy, gzip, bzip2, tar, tar.gz, tar.bz2, exclude, gzip, bzip2, zip, diff, diff.bz2, diff.gz. Каждая директива имеет следующий синтаксис аргументов:

• spec: путь_к_файлу - использовать данный specfile для работы gear
• tags: путь_к_каталогу - позволяет указать путь к каталогу, содержащему gear-tags, вместо стандартного .gear-tags/
• copy: glob_pattern... - копировать в пакет файлы, попадающие под glob_pattern
• gzip: glob_pattern..., bzip2: glob_pattern... - по аналогии с copy, но ещё сжимает копируемые файлы
• copy?: glob_pattern..., gzip?: glob_pattern..., bzip2?: glob_pattern.. - по аналогии с copy, но не выводить ошибку при отсутствии данных файлов. Полезно в случае переодического использования патчей
• exclude: glob_pattern... - исключать из копирования определённые файлы.
• tar: tree_path [options...] - создавать тарболл (архив tar) с деревом, определяемом в tree_path. Допустимые опции:
  • spec=path_to_file - использовать другой specfile для определения значений ключей
  • name=archive_name - устанавливает имя создаваемого архива (суффикс tar (или иной, определённый опцией suffix) добавляется автоматически). По умолчанию эта опция выставлена в значение @dir@-@version@, если tree-path выставлен в . , иначе значение по умолчанию - @name@-@version@
  • base=base_name - добавить base_name в качестве первого каталога ко всем файлам архива. Если опция не указана, то используется имя архива без суффикса (например @name@-@version@)
  • suffix=suffix - использовать другой суффикс архива вместо .tar
• tar.gz: tree_path [options...], tar.bz2: tree_path [options...] - по аналогии с tar, но создаёт сжатые архивы. Соответственно меняется суффикс по умолчанию на tar.gz или tar.bz2
• zip: tree_path [options...] - по аналогии с tar, но создаёт архив zip, соответственно изменяя суффикс
• tar?: tree_path [options...], tar.gz?: tree_path [options...], tar.bz2?: tree_path [options...], zip?: tree_path [options...] - работают по аналогии с директивами без "?", но не выводят ошибку в случае отсутствия tree_path в репозитории.
• diff: old_tree_path new_tree_path [options...] - создаёт патч между оригинальным деревом (old_tree_path) и изменённым деревом (new_tree_path). Оба дерева должны обязательно существовать в git репозитории. Доступные опции:
  • spec=path_to_file - путь к спекфайлу, позволяет использовать другой, отличный от основного спекфайл для получения значений ключевых слов (version, например)
  • name=diff_name - устанавливает имя генерируемого патча. По умолчанию патч создаётся с именем @new_dir@-@version@-@release@.patch. Если в качестве каталога используется ., то патч будет создан с именем @name@-@version@-@release@.patch. Значение опции "name" может содержать ключевые слова, дополнительные к стандартным: @old_dir@ и @new_dir@, которые раскрываются в имя последнего каталога (basename, по факту) из old_tree_path и new_tree_path.
• diff.gz: old_tree_path new_tree_path [options...], diff.bz2: old_tree_path new_tree_path [options...] - работает по аналогии с директивой diff, но создаёт сжатые соответсвующими алгоритмами патчи
• diff?: old_tree_path new_tree_path [options...], diff.gz?: old_tree_path new_tree_path [options...], diff.bz2?: old_tree_path new_tree_path [options...] - работает по аналогии с diff, diff.gz и diff.bz2, но не выдаёт ошибку в случае невозможности создать патч (например из-за отсутствия какого-то из бранчей).

Допустимые ключевые слова:

• @dir@ - basename(путь_к_каталогу);
• @name@ - Имя пакета, добытое из спекфайла
• @version@ - Версия пакета, добытая из спекфайла
• @release@ - релиз (номер сборки) пакета, добытый из спекфайла

Сборка пакета

Для сборки пакетов необходимо использовать gear. Вы должны чётко понимать, что gear использует git для получения файлов, поэтому все изменения, которые не внесены в репозиторий (для которых не выполнен commit) - gear учитывать не будет.

Локальная сборка:

gear --rpmbuild -- <команда rpmbuild>

Например:

gear --rpmbuild -- rpmbuild -ba

Сборка в hasher:

gear --hasher -- <команда hsh>

Например:

gear --hasher -- hsh /path/to/workdir

Для сборки со временным коммитом изменений: gear --commit --hasher -- hsh

NB:

Когда hasher собирает gear-пакет, сборочные зависимости ставятся трижды:
1. BuildRequires(pre): для того, чтобы работал rpmbuild -bE.
2. BuildRequires: для того, чтобы работал rpmbuild -bs.
3. Зависимости srpm-пакета: для того, чтобы работал rpmbuild --rebuild.

ldv@

XX

При необходимости добавить ещё один remote branch в ваш репозиторий, например ваш собственный или тех, кто вносил изменения в ваш проект:

git remote add <имя бранча> <URL>

Для загрузки remote branch воспользуйтесь командой:

git fetch <имя бранча>

Просмотреть все внешние бранчи можно командой:

git remote

А просмотреть информацию о каком-то бранче можно командой:

git remote show <имя бранча, например origin>

Приспосабливаем rpmwrap

Часто у мантейнера нет желания делать commit в локальный GIT репозиторий, не проверив пакет на собираемость. Для того, что бы собирать пакеты локально rpm'ом - необходим rpmwrapper, переопределяющий пути к исходникам пакета.

Забрать rpmwrapper: apt-get install rpmwrap

после этого необходимо в $HOME/bin/ сделать следущие симлинки: $HOME/bin/rpm -> /usr/bin/rpmwrap $HOME/bin/rpmbuild -> /usr/bin/rpmwrap

или использовать команды rpmwrap-rpm и rpmwrap-rpmbuild

Для настройки rpmwrapper добавьте в свой домашний каталог файл .rpmwraprc с таким содержимым:

RPM_PREFIX="/usr/bin"
RPM="$RPM_PREFIX/rpm"
macrofile=".rpmwrapmacros"
allow_prefix="$HOME/src/RPM:$HOME/src/sisyphus/packages"

Где allow_prefix содержит все пути, в которых могут быть пакеты.

Для использования rpmwrapper в каталог пакета необходимо положить файл .rpmwrapmacros с примерно таким содержимым:

%_topdir        %_macropath
%_sourcedir     %{_topsrcdir}
%_specdir       %{_topsrcdir}
%_tmppath       %{_topsrcdir}/tmp

Где %_macropath будет определяться rpmwrapper'ом и содержать путь к файлу .rpmwrapmacros. После этого можно выполнять rpm -ba <спек файл>, находясь в каталоге git-репозитория пакета.

BuildPreReq vs BuildRequires(pre)

* gvy попытался напустить gear на vim-plugin-deldiff
<gvy> error: line 8: Tag takes single token only: Url: %vim_script_url 444 :-(
<vsu> gvy: BuildRequires(pre): vim-devel ?
<gvy> vsu, ну я пока не понял -- как оно попало в сизиф, если gear не может собрать
<vsu> gvy: gear --hasher не может
<vsu> gvy: gear --rpmbuild, вероятно, может
<gvy> vsu, Ааа
<gvy> vsu, точно
<vsu> gvy: ну зафикси да выложи :)
<gvy> vsu, кого -- gear? :)
<gvy> там BuildPreReq: vim-devel
<vsu> gvy: а надо BuildRequires(pre)
<vsu> sed '/^buildrequires(pre):[[:space:]]*/I!d;s///' "\$HOME/in/spec"/* |
<vsu>         /.host/filter_spec_buildreq
<vsu> gvy: это в hasher забито

Ссылки

• Everyday GIT
• Пример работы с gear-tags
• Ещё о работе с git и git.alt