Дополнительные статьи:
Пример работы с gear-tags
gear – инструмент, позволяющий использовать git для хранения исходных пакетов.
Что нужно:
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 при сборке пакетов, должен содержать строки в следующем формате:
директива: аргументы...
Все пустые строки, а также строки, начинающиеся с # – игнорируются
Доступные директивы: 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.
примеры 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.
В ALT Linux есть возможность для мантейнеров создавать публичные репозитарии GIT, а для пользователей – брать с этих репозитариев данные, используя различные схемы доступа.
Для доступа к git репозитарию мантейнеров на запись есть только один протокол – ssh.
Настройка ssh для работы с git.alt выглядит следующим образом:
Для того, что бы сделать нормальный (полнофункциональный) удалённый репозитарий, с доступом через 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 ;)
Часто у мантейнера нет желания делать 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-репозитария пакета.