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

Материал из ALT Linux Wiki
(Import from freesource.info)
 
(не показано 9 промежуточных версий 5 участников)
Строка 1: Строка 1:
[[Category:Devel]]
{{stub}}
{{MovedFromFreesourceInfo|AltLinux/Sisyphus/devel/gear/geartags}}
== Пример использования .gear/tags ==


== Использование .gear-tags ==
Цель использования gear tags получить в .src.rpm-е тарбол оригинальных сырцов + кумулятивный патч наших изменений.
 
Цель использования gear-tags - получить в .src.rpm-е тарбол оригинальных сырцов + кумулятивный патч наших изменений.


Структура репозитория должна быть примерно такой:
Структура репозитория должна быть примерно такой:
* '''upstream''' - сюда импортятся оригинальные тарболы один за другим, при этом проставляются таги с именем "vверсия", т.е. v1.0, v2.0, v3.0 и т.д
* '''upstream''' сюда импортятся оригинальные тарболы один за другим, при этом проставляются таги с именем «vверсия», то есть v1.0, v2.0, v3.0 и т.д
* '''master''' - это наш рабочий бранч, тут мы храним спек, дополнительные sources и изменённые исходники. На каждый релиз пакета проставляются таги вида %version-%release, т.е. 1.0-alt1, 1.0-alt2, 1.0-alt3 и т.д.
* '''master''' это наш рабочий бранч, тут мы храним спек, дополнительные sources и изменённые исходники. На каждый релиз пакета проставляются таги вида %version-%release, то есть 1.0-alt1, 1.0-alt2, 1.0-alt3 и т. д.
'''master''' и '''upstream''' связаны следующим образом: когда-то, сразу после прикладывания патчей (версия нашего проекта foo совпадает в master и upstream) для создания общего base, в бранче master был выполнен
'''master''' и '''upstream''' связаны следующим образом: когда-то, сразу после прикладывания патчей (версия нашего проекта foo совпадает в master и upstream) для создания общего base, в бранче master был выполнен
<pre>git pull -s ours . upstream</pre>
<pre>git merge -s ours upstream</pre>


В дальнейшем, при обновлении версии, производится
В дальнейшем, при обновлении версии, производится
<pre>git pull . upstream</pre>
<pre>git merge upstream</pre>
 
При этом все наши интегрированные патчи, спек, sources — сохраняются. Если возникает конфликт, git об этом напишет, остаётся лишь устранить его (например, воспользовавшись '''git mergetool''').


При этом все наши интегрированные патчи, спек, sources - сохраняются. Если возникает конфликт, git об этом напишет, остаётся лишь устранить его.
Для реализации поставленной задачи необходимо несколько вникнуть в применение директив файла '''.gear/rules''', и соответствующим образом его модифицировать. Найти информацию можно в заголовке '''/usr/bin/gear''' или в man-странице '''gear-rules(5)'''


Для реализации поставленной задачи необходимо несколько вникнуть в применение директив файла '''.gear-rules''', и соответствующим образом его модифицировать. Найти информацию можно в заголовке '''/usr/bin/gear''' или в man-странице '''gear-rules(5)'''
Итак, нам необходимо, чтобы в тарбол помещалось оригинальное дерево исходников:
Итак, нам необходимо, чтобы в тарбол помещалось оригинальное дерево исходников:
<pre>tar: v@version@:foo</pre>
<pre>tar: v@version@:foo</pre>


В данном случае мы говорим, что tar-файл необходимо завернуть директорию '''foo''', которая должна быть взята из тага '''v@version@'''. Так же можно использовать не таг, а непосредственно идентификатор коммита (sha1 хэш)
В данном случае мы говорим, что в tar-файл необходимо завернуть директорию '''foo''', которая должна быть взята из тага '''v@version@'''. Так же можно использовать не таг, а непосредственно идентификатор коммита (sha1 хэш).
'''@version@''' - это тот '''Version''', что прописан в спеке.
'''@version@''' это тот тег '''Version:''', что прописан в спеке.


Теперь нужно сделать кумулятивный diff:
Теперь нужно сделать кумулятивный diff:
<pre>diff: v@version@:foo foo</pre>
<pre>diff: v@version@:foo foo</pre>
Здесь тоже всё просто - делается diff между директорией foo тага '''v@version@''' и директорий '''foo''' из текущего бранча ('''master'''). Имя diff-а по умолчанию '''%name-%version-%release.patch'''.
Здесь тоже всё просто делается diff между директорией foo тага '''v@version@''' и директорий '''foo''' из текущего бранча ('''master'''). Имя diff-а по умолчанию '''%name-%version-%release.patch'''. Разумеется, название diff-а в спеке должно указывать на правильный patch-файл.


Осталось сформировать список тагов, с которыми должен работать gear. Для этого предназначена специальная утилита '''gear-update-tag(1)'''
Осталось сформировать файл с состоянием тэгов на текущий момент времени (этот файл в дальнейшем позволит пересобирать пакет вне зависимости от того, куда и как были переставлены тэги, упоминаемые в файле <tt>.gear/rules</tt>). Для этого предназначена специальная утилита '''gear-update-tag(1)'''
<pre>gear-update-tag  -ac</pre>
<pre>gear-update-tag  -ac</pre>


И не забыть закоммитить:
И не забыть закоммитить:
<pre>git commit -a -m 'Switched to use .gear-tags'</pre>
<pre>git commit -a -m 'Switched to use .gear/tags'</pre>
 
==Накладываемые ограничения==
Ограничения, накладываемые на ссылки на другие коммиты, необходимы для того, чтобы репозиторий, содержащий основной коммит, содержал всё, что требуется для однозначного извлечения исходного кода.
 
В частности, если в коммите C вы ссылаетесь на некоторый коммит с помощью .gear/rules, то необходимо, чтобы этот коммит был среди предков коммита C -- тогда git обеспечит обязательное присутствие коммита в репозитории до тех пор, пока в нём находится коммит C.
 
Идея, лежащая в основе ограничения, простая: необходимо обеспечить, чтобы всякий раз из коммита C собиралось одно и то же.
 
 
{{Category navigation|title=gear|category=gear|sortkey={{SUBPAGENAME}}}}

Версия от 12:34, 28 июля 2011

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Пример использования .gear/tags

Цель использования gear tags — получить в .src.rpm-е тарбол оригинальных сырцов + кумулятивный патч наших изменений.

Структура репозитория должна быть примерно такой:

  • upstream — сюда импортятся оригинальные тарболы один за другим, при этом проставляются таги с именем «vверсия», то есть v1.0, v2.0, v3.0 и т.д
  • master — это наш рабочий бранч, тут мы храним спек, дополнительные sources и изменённые исходники. На каждый релиз пакета проставляются таги вида %version-%release, то есть 1.0-alt1, 1.0-alt2, 1.0-alt3 и т. д.

master и upstream связаны следующим образом: когда-то, сразу после прикладывания патчей (версия нашего проекта foo совпадает в master и upstream) для создания общего base, в бранче master был выполнен

git merge -s ours upstream

В дальнейшем, при обновлении версии, производится

git merge upstream

При этом все наши интегрированные патчи, спек, sources — сохраняются. Если возникает конфликт, git об этом напишет, остаётся лишь устранить его (например, воспользовавшись git mergetool).

Для реализации поставленной задачи необходимо несколько вникнуть в применение директив файла .gear/rules, и соответствующим образом его модифицировать. Найти информацию можно в заголовке /usr/bin/gear или в man-странице gear-rules(5)

Итак, нам необходимо, чтобы в тарбол помещалось оригинальное дерево исходников:

tar: v@version@:foo

В данном случае мы говорим, что в tar-файл необходимо завернуть директорию foo, которая должна быть взята из тага v@version@. Так же можно использовать не таг, а непосредственно идентификатор коммита (sha1 хэш). @version@ — это тот тег Version:, что прописан в спеке.

Теперь нужно сделать кумулятивный diff:

diff: v@version@:foo foo

Здесь тоже всё просто — делается diff между директорией foo тага v@version@ и директорий foo из текущего бранча (master). Имя diff-а по умолчанию %name-%version-%release.patch. Разумеется, название diff-а в спеке должно указывать на правильный patch-файл.

Осталось сформировать файл с состоянием тэгов на текущий момент времени (этот файл в дальнейшем позволит пересобирать пакет вне зависимости от того, куда и как были переставлены тэги, упоминаемые в файле .gear/rules). Для этого предназначена специальная утилита gear-update-tag(1)

gear-update-tag  -ac

И не забыть закоммитить:

git commit -a -m 'Switched to use .gear/tags'

Накладываемые ограничения

Ограничения, накладываемые на ссылки на другие коммиты, необходимы для того, чтобы репозиторий, содержащий основной коммит, содержал всё, что требуется для однозначного извлечения исходного кода.

В частности, если в коммите C вы ссылаетесь на некоторый коммит с помощью .gear/rules, то необходимо, чтобы этот коммит был среди предков коммита C -- тогда git обеспечит обязательное присутствие коммита в репозитории до тех пор, пока в нём находится коммит C.

Идея, лежащая в основе ограничения, простая: необходимо обеспечить, чтобы всякий раз из коммита C собиралось одно и то же.