Gear/old

Материал из ALT Linux Wiki

Перейти к: навигация, поиск
42px-Wikitext-ru.svg.png
Эту статью следует викифицировать.
Freesource-logo.png Blue Glass Arrow.svg MediaWiki logo.png
Эта страница была перемещена с freesource.info.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.

[править] Использование 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 забито

[править] Ссылки


 
Личные инструменты