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.alt