Gear/old
Материал из ALT Linux Wiki
[править] Использование 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.
[править] 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 забито
[править] Ссылки
