Gear/old: различия между версиями

Материал из ALT Linux Wiki
м (Страница giteveryday(7) переехала)
 
(не показано 8 промежуточных версий 7 участников)
Строка 1: Строка 1:
[[Category:Devel]]
{{Викифицировать}}
{{Викифицировать}}
{{MovedFromFreesourceInfo|AltLinux/Sisyphus/devel/gear}}
{{MovedFromFreesourceInfo|AltLinux/Sisyphus/devel/gear}}
== Использование gear/git ==
== Использование gear/git ==


__TOC__
__TOC__


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


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


Что нужно:
Что нужно:
Строка 18: Строка 15:


=== Как работает gear ===
=== Как работает gear ===
Gear - инструмент, позволяющий оперируя данными из git репозитария проводить сборку исходного текста в rpm пакет,тарболл или просто экспортировать результаты выполненияправил (gear-rules) в определённый каталог.   
Gear - инструмент, позволяющий оперируя данными из git репозитория проводить сборку исходного текста в rpm пакет,тарболл или просто экспортировать результаты выполненияправил (gear-rules) в определённый каталог.   


В своей работе gear использует файл .gear-rules, являющийся частью репозитария, В данном файле описывается то, что нужно сделать gear что бы получить файлы, необходимые для сборки rpm пакета с помощью spec,  
В своей работе gear использует файл .gear-rules, являющийся частью репозитория, В данном файле описывается то, что нужно сделать gear что бы получить файлы, необходимые для сборки rpm пакета с помощью spec,  


Так как gear берёт все данные исключительно из git репозитария, и пользуется для этого исключительно набором утилит git, то все изменения должны быть в обязательном порядке внесены в репозитарий командой git-commit -a. Иначе gear будет работать с предыдущими данными и все последние изменения использоваться при сборке не станут. Но для тестирования некоторых коммитов у gear есть замечательная опция --commit, позволяющая выполнить так называемый временный коммит всех текущих изменений и использовать его исключительно для сборки, откатив в дальнейшем. Но даже с этой опцией безусловно предварительно нужно выполнить git-add для всех новых файлов и git-rm для всех файлов, подлежащих удалению.  
Так как gear берёт все данные исключительно из git репозитория, и пользуется для этого исключительно набором утилит git, то все изменения должны быть в обязательном порядке внесены в репозиторий командой git-commit -a. Иначе gear будет работать с предыдущими данными и все последние изменения использоваться при сборке не станут. Но для тестирования некоторых коммитов у gear есть замечательная опция --commit, позволяющая выполнить так называемый временный коммит всех текущих изменений и использовать его исключительно для сборки, откатив в дальнейшем. Но даже с этой опцией безусловно предварительно нужно выполнить git-add для всех новых файлов и git-rm для всех файлов, подлежащих удалению.  


gear позволяет собирать пакет как с помощью обычного системного rpm, в системном окружении, так и с помощью hasher в создаваемом с нуля чруте.
gear позволяет собирать пакет как с помощью обычного системного rpm, в системном окружении, так и с помощью hasher в создаваемом с нуля чруте.
Преимущества использования gear для мантейнера вполне очевидны:
Преимущества использования gear для мантейнера вполне очевидны:
* возможность использования в процессе сборки и разработки пакета всех достоинств репозитария git, основное из которых - хранение истории всех изменений плюс ведение нескольких веток
* возможность использования в процессе сборки и разработки пакета всех достоинств репозитория git, основное из которых - хранение истории всех изменений плюс ведение нескольких веток
* унифицированный механизм сборки и публикации исходных текстов пакета.  
* унифицированный механизм сборки и публикации исходных текстов пакета.  
* удобный интерфейс с rpm и hasher
* удобный интерфейс с rpm и hasher
* возможность (теоретическая, я не знаю практических примеров), сборки из одного репозитария пакета для разных дистрибутивов Linux
* возможность (теоретическая, я не знаю практических примеров), сборки из одного репозитория пакета для разных дистрибутивов Linux
* значительная экономия трафика при выкладывании и получении обновлений уже загруженных ранее git репозитариев
* значительная экономия трафика при выкладывании и получении обновлений уже загруженных ранее git репозиториев
* возможность ведения нескольких веток одного проекта разными разработчикам, с дальнейшей процедурой объединения изменений.  
* возможность ведения нескольких веток одного проекта разными разработчикам, с дальнейшей процедурой объединения изменений.  


Говоря о преимуществах, не стоит забывать и про недостатки, самым основным из которых я вижу невозможность получения только последней версии git-репозитария, исключая необходимость загружать к себе всю историю ведения пакета. Наличие такой возможности позволило бы значительно экономить сетевой трафик. Для примера - git репозитарий ядра в ALT Linux - это порядка 100 мегабайт. И это всё нужно выкачать любому, кто захочет из gear собрать свежее ядро. Загрузка же только последней ревизии git репозитария ядра должна была бы весить около 30 мегабайт. Разница ощутима, и она будет расти по мере внесения изменений в git репозитарий.  
Говоря о преимуществах, не стоит забывать и про недостатки, самым основным из которых я вижу невозможность получения только последней версии git-репозитория, исключая необходимость загружать к себе всю историю ведения пакета. Наличие такой возможности позволило бы значительно экономить сетевой трафик. Для примера - git репозиторий ядра в ALT Linux - это порядка 100 мегабайт. И это всё нужно выкачать любому, кто захочет из gear собрать свежее ядро. Загрузка же только последней ревизии git репозитория ядра должна была бы весить около 30 мегабайт. Разница ощутима, и она будет расти по мере внесения изменений в git репозиторий.  


=== Импорт пакетов: ===
=== Импорт пакетов: ===
Итак, какие действия нужно выполнить для начала работы с gear/git ? Первое - это import существующего пакета (или загрузка его с публичного git-репозитария). Для импорта необходимо выполнить следующие действия:
Итак, какие действия нужно выполнить для начала работы с gear/git ? Первое - это import существующего пакета (или загрузка его с публичного git-репозитория). Для импорта необходимо выполнить следующие действия:
<pre>mkdir <имя-пакета>
<pre>mkdir <имя-пакета>
cd <имя-пакета>
cd <имя-пакета>
git-init
git init
gear-srpmimport -<srpm-пакеты></pre>
gear-srpmimport <srpm-пакеты></pre>


После того, как в текущем каталоге создан git-репозиторий, содержащий исходный код пакетов, рекомендуется пройтись по автоматически созданному во время импорта файлу .gear-rules.
После того, как в текущем каталоге создан git-репозиторий, содержащий исходный код пакетов, рекомендуется пройтись по автоматически созданному во время импорта файлу .gear-rules.
Строка 60: Строка 57:
Все пустые строки, а также строки , начинающиеся с # - игнорируются
Все пустые строки, а также строки , начинающиеся с # - игнорируются


Доступные директивы: spec, tags, copy, gzip, bzip2, tar, tar.gz, tar.bz2, exclude, gzip, bzip2, zip, diff, diff.bz2, diff.gz  
Доступные директивы: 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/
'''''spec: путь_к_файлу''''' - использовать данный specfile для работы gear
* '''''copy: glob_pattern...''''' - копировать в пакет файлы, попадающие под glob_pattern
'''''tags: путь_к_каталогу'''''  - позволяет указать путь к каталогу, содержащему gear-tags, вместо стандартного .gear-tags/
* '''''gzip: glob_pattern...''''', '''''bzip2: glob_pattern...''''' - по аналогии с copy, но ещё сжимает копируемые файлы
'''''copy: glob_pattern...''''' - копировать в пакет файлы, попадающие под glob_pattern
* '''''copy?: glob_pattern...''''', '''''gzip?: glob_pattern...''''', '''''bzip2?: glob_pattern..''''' - по аналогии с copy, но не выводить ошибку при отсутствии данных файлов. Полезно в случае переодического использования патчей
'''''gzip: glob_pattern...'''''
* '''''exclude: glob_pattern...''''' - исключать из копирования определённые файлы.
'''''bzip2: glob_pattern...''''' - по аналогии с copy, но ещё сжимает копируемые файлы
* '''''tar: tree_path [options...]''''' - создавать тарболл (архив tar) с деревом, определяемом в tree_path. Допустимые опции:
'''''copy?: glob_pattern...'''''
** ''spec=path_to_file'' - использовать другой specfile для определения значений ключей
'''''gzip?: glob_pattern...'''''
** ''name=archive_name'' - устанавливает имя создаваемого архива (суффикс tar (или иной, определённый опцией suffix) добавляется автоматически). По умолчанию эта опция выставлена в значение @dir@-@version@, если tree-path выставлен в . , иначе значение по умолчанию - @name@-@version@
'''''bzip2?: glob_pattern..''''' - по аналогии с copy, но не выводить ошибку при отсутствии данных файлов. Полезно в случае переодического использования патчей
** ''base=base_name'' - добавить base_name в качестве первого каталога ко всем файлам архива. Если опция не указана, то используется имя архива без суффикса (например @name@-@version@)
'''''exclude: glob_pattern...''''' - исключать из копирования определённые файлы.
** ''suffix=suffix'' - использовать другой суффикс архива вместо .tar
'''''tar: tree_path [options...]''''' - создавать тарболл (архив tar) с деревом, определяемом в tree_path. Допустимые опции:
* '''''tar.gz: tree_path [options...]''''', '''''tar.bz2: tree_path [options...]''''' - по аналогии с tar, но создаёт сжатые архивы. Соответственно меняется суффикс по умолчанию на tar.gz или tar.bz2
* ''spec=path_to_file'' - использовать другой specfile для определения значений ключей
* '''''zip: tree_path [options...]''''' - по аналогии с tar, но создаёт архив zip, соответственно изменяя суффикс
* ''name=archive_name'' - устанавливает имя создаваемого архива (суффикс tar (или иной, определённый опцией suffix) добавляется автоматически). По умолчанию эта опция выставлена в значение @dir@-@version@, если tree-path выставлен в . , иначе значение по умолчанию - @name@-@version@
* '''''tar?: tree_path [options...]''''', '''''tar.gz?: tree_path [options...]''''', '''''tar.bz2?: tree_path [options...]''''', '''''zip?: tree_path [options...]''''' - работают по аналогии с директивами без "?", но не выводят ошибку в случае отсутствия tree_path в репозитории.
* ''base=base_name'' - добавить base_name в качестве первого каталога ко всем файлам архива. Если опция не указана, то используется имя архива без суффикса (например @name@-@version@)
* '''''diff: old_tree_path new_tree_path [options...]''''' - создаёт патч между оригинальным деревом (old_tree_path) и изменённым деревом (new_tree_path). Оба дерева должны обязательно существовать в git репозитории.  Доступные опции:
* ''suffix=suffix'' - использовать другой суффикс архива вместо .tar
** '''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.  
'''''tar.gz: tree_path [options...]'''''
*'''''diff.gz: old_tree_path new_tree_path [options...]''''', '''''diff.bz2: old_tree_path new_tree_path [options...]''''' - работает по аналогии с директивой diff, но создаёт сжатые соответсвующими алгоритмами патчи
'''''tar.bz2: tree_path [options...]''''' - по аналогии с tar, но создаёт сжатые архивы. Соответственно меняется суффикс по умолчанию на tar.gz или tar.bz2
*'''''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, но не выдаёт ошибку в случае невозможности создать патч (например из-за отсутствия какого-то из бранчей).  
 
'''''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(путь_к_каталогу);
* @dir@ - basename(путь_к_каталогу);
@name@ - Имя пакета, добытое из спекфайла
* @name@ - Имя пакета, добытое из спекфайла
@version@ - Версия пакета, добытая из спекфайла
* @version@ - Версия пакета, добытая из спекфайла
@release@ - релиз (номер сборки) пакета, добытый из спекфайла
* @release@ - релиз (номер сборки) пакета, добытый из спекфайла


=== Сборка пакета ===
=== Сборка пакета ===
Для сборки пакетов необходимо использовать gear. Вы должны чётко понимать, что gear использует git для получения файлов, поэтому все изменения, которые не внесены в репозитарий (для которых не выполнен commit) - '''gear учитывать не будет'''.
Для сборки пакетов необходимо использовать gear. Вы должны чётко понимать, что gear использует git для получения файлов, поэтому все изменения, которые не внесены в репозиторий (для которых не выполнен commit) - '''gear учитывать не будет'''.


Локальная сборка:
Локальная сборка:
Строка 126: Строка 105:
''[http://lists.altlinux.org/pipermail/devel/2007-April/044401.html ldv@]''
''[http://lists.altlinux.org/pipermail/devel/2007-April/044401.html ldv@]''


=== Повседневное использование ===
Вот стандартный набор команд, которые необходимы для работы с 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.




== XX ==
== XX ==


При необходимости добавить ещё один remote branch в ваш репозитарий, например  ваш собственный или тех, кто вносил изменения в ваш проект:
При необходимости добавить ещё один remote branch в ваш репозиторий, например  ваш собственный или тех, кто вносил изменения в ваш проект:
<pre>git remote add <имя бранча> <URL></pre>
<pre>git remote add <имя бранча> <URL></pre>
Для загрузки remote branch воспользуйтесь командой:
Для загрузки remote branch воспользуйтесь командой:
<pre>git-fetch <имя бранча></pre>
<pre>git fetch <имя бранча></pre>
Просмотреть все внешние бранчи можно командой:
Просмотреть все внешние бранчи можно командой:
<pre>git remote</pre>
<pre>git remote</pre>
Строка 156: Строка 122:
=== Приспосабливаем rpmwrap ===
=== Приспосабливаем rpmwrap ===


Часто у мантейнера нет желания делать commit в локальный GIT репозитарий, не проверив пакет на собираемость.
Часто у мантейнера нет желания делать commit в локальный GIT репозиторий, не проверив пакет на собираемость.
Для того, что бы собирать пакеты локально rpm'ом - необходим rpmwrapper, переопределяющий пути к исходникам пакета.
Для того, что бы собирать пакеты локально rpm'ом - необходим rpmwrapper, переопределяющий пути к исходникам пакета.


Строка 181: Строка 147:
%_tmppath      %{_topsrcdir}/tmp</pre>
%_tmppath      %{_topsrcdir}/tmp</pre>
Где %_macropath будет определяться rpmwrapper'ом и содержать путь к файлу .rpmwrapmacros.
Где %_macropath будет определяться rpmwrapper'ом и содержать путь к файлу .rpmwrapmacros.
После этого можно выполнять rpm -ba <спек файл>, находясь в каталоге git-репозитария пакета.
После этого можно выполнять rpm -ba <спек файл>, находясь в каталоге git-репозитория пакета.


=== BuildPreReq vs BuildRequires(pre) ===
=== BuildPreReq vs BuildRequires(pre) ===
Строка 201: Строка 167:


=== Ссылки ===
=== Ссылки ===
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT]
* [https://mirrors.edge.kernel.org/pub/software/scm/git/docs/giteveryday.html Everyday GIT]
* [http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/gear/gear-tags Пример работы с gear-tags]
* [[Gear/tags|Пример работы с gear-tags]]
* [http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/git Ещё о работе с git.alt]
* Ещё о работе с [[git]] и [[git.alt]]
 
 
{{Category navigation|title=gear|category=gear|sortkey={{SUBPAGENAME}}}}

Текущая версия от 13:33, 28 мая 2019

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 забито

Ссылки