Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/devel/gear ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия AltLinux/Sisyphus/devel/gear за 2007-09-24 22:07:54..

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


Оглавление документа


Дополнительные статьи:
Пример работы с gear-tags


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


Что нужно:

Как работает 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-репозитария, исключая необходимость загружать к себе всю историю ведения пакета. Наличие такой возможности позволило бы значительно экономить сетевой трафик. Для примера – 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-rules


Файл с правилами, описывающими поведение 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. Допустимые опции:


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 репозитарии. Доступные опции:


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@

Релиз пакета

примеры raorn@
echo “sisyphus” >> .git/gear/release-tags
gear-release --sign=raorn@alt --create -n vim sisyphus v7.0.109-alt1
сделает тег v7.0.109-alt1 (/me юзает v%version-%release с текстом "%name %version-%release" обычно)
и ещё сделает тег release/sisyphus на него же

Повседневное использование


Вот стандартный набор команд, которые необходимы для работы с gear/git:


cg-clone (git-clone) <путь к репозитарию>: сделать локальную копию репозитария, при этом ветка origin будет удалённый репозитарий
cg-fetch (git-fetch, git-pull): обновиться с удалённого репозитария
cg-diff (git-diff): посмотреть изменения между локальным репозитарием и исправленными файлами
cg-commit (git-commit): выполнить коммит всех локальных изменений в локальный репозитарий
cg-push (git-push): выложить изменения в локальном репозитарии на удалённый репозитарий
cg-log (git-log, git-whatchanged): посмотреть изменения в репозитарии
cg-tag (git-tag): установить метку(tag)


Синтаксис этих команд не имеет смысла описывать, по каждой из них есть вполне подробный man.

GIT.ALT – для мантейнеров и пользователей


В ALT Linux есть возможность для мантейнеров создавать публичные репозитарии GIT, а для пользователей – брать с этих репозитариев данные, используя различные схемы доступа.


Для доступа к git репозитарию мантейнеров на запись есть только один протокол – ssh.
Настройка ssh для работы с git.alt выглядит следующим образом:


Данный настроек должно быть достаточно, для того, что бы вы могли делать commit, push, pull репозитария на git.alt.


Теперь необходимо выполнить предварительную настройку git.alt для себя. Для этого необходимо получить репозитарий с настройками, находящийся по адресу:
git+ssh://git.alt/people/<ваш login>/etc/packages.git


Т.е. – нужно выполнить команду:
git-clone git+ssh://git.alt/people/<ваш login>/etc/packages.git


В текущем каталоге будет создан подкаталог packages, содержащий каталог .git, файл email-distribution и файл email-subscription. В первом файле вы настраиваете отправку писем обо всех изменениях в вашем репозитарии другим пользователям git.alt, а во втором – получение вами писем обо всех изменениях в других репозитариях. Рекомендуется заполнять только файл email-subscription, при чём для каждого из параметров ставить '*". В этом случае вы будете получать информацию обо всех изменениях во всех репозитариях и бранчах ваших коллег.


После того, как соответствующие изменения в файлы внесены – выполните команды: git-commit -a -m “Updated setup” и git-push для публикации настроек на сервере.


Для read-only анонимного доступа к репозитарию ALT Linux воспрользуйтесь анонимным интерфейсом: git://git.altlinux.org/.
Посмотреть какие репозитарии расположены на git.altlinux.org можно через web-интерфейс

создание remote-репозитария


Для того, что бы сделать нормальный (полнофункциональный) удалённый репозитарий, с доступом через ssh и возможностью нескольким человекам работать над одним проектом, вам потребуется сервер с установленным git'ом и ssh-доступом к этому серверу.


я для себя решил следущим образом:
– на сервере создал группу, входящие в которую разработчики получают права на изменения в git репозитарии
– создал отдельный каталог (допустим /disk/git), сменил на него права: 775, SGID на группу, группа gitdevelopers


После этого все разработчики получили возможность выкладывать в этот каталог свои git репозитарии.


Это не идеальное решение, и предложения здесь приветствуются.


Импорт проекта в remote-репозитарий


Для начала необходимо склонировать текущий репозитарий, убрав из него всё лишнее:
git prune
git-repack -a -d


mkdir /tmp/export
pushd /tmp/export
git-clone --bare <путь к локальному репозитарию> <репозитарий.git>


Включаем post-update hook, который вызывает git-update-server-info (нужен для http и rsync методов доступа):
chmod +x <репозитарий.git>/hooks/post-update


Далее – выкладываем созданный <репозитарий.git> на сервер через rsync:
rsync -vaP -e ssh <репозитарий.git> сервер:/disk/git/


где /disk/git/ – это собственно путь к хранилищу git репозитариев на сервере


после этого заходим на сервер и меняем владельца репозитария, выставляя группу и права группе на запись к файлам репозитария.


не стоит забывать добавлять remote-branch в локальный репозитарий (cg-branch-add), и выполнять время-от-времени в него cg-push ;)

Приспосабливаем 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-репозитария пакета.

Ссылки


Страницы, ссылающиеся на данную: AltLinux/Sisyphus
AltLinux/Sisyphus/devel/gear/ImportSeparateUpstream
AltLinux/Sisyphus/devel/gear/ImportUpstreamVBranch
AltLinux/Sisyphus/devel/git


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]