Руководство по gear: различия между версиями

Материал из ALT Linux Wiki
(Новая: Категория:Sisyphus Категория:Devel Категория:Руководства {{Stub}} == Паттерны ведения пакетов в <tt>gear</tt> ==...)
 
Нет описания правки
(не показаны 22 промежуточные версии 9 участников)
Строка 1: Строка 1:
[[Категория:Sisyphus]]
[[Категория:Руководства|gear]]
[[Категория:Devel]]
[[en:Gear/Introduction]]
[[Категория:Руководства]]
{{Stub}}
{{Stub}}


== Паттерны ведения пакетов в <tt>gear</tt> ==
== Паттерны ведения пакетов в <tt>gear</tt> ==


<tt>gear</tt> спроектирован для сборки пакетов из произвольно устроенного <tt>git</tt>-репозитория, но при этом среди <tt>gear</tt>-репозиториев наиболее часто встречаются следующие варианты:
<tt>gear</tt> спроектирован для сборки пакетов из произвольно устроенного <tt>git</tt>-репозитория, но при этом среди <tt>gear</tt>-репозиториев наиболее часто встречаются следующие варианты.


TODO: gear-srpmimport, gear-buildreq, gear-changelog, gear-commit, gear[-remote][{,-hsh,-rpm}]
TODO: gear-srpmimport, gear-buildreq, gear-changelog, gear-commit, gear[-remote][{,-hsh,-rpm}], [[Gear/gear-uupdate|gear-uupdate]].


=== "Родной" репозиторий ===
== «Родной» репозиторий ==


Если пакет разрабатывается целиком в рамках Sisyphus, то в этом случае нет необходимости отслеживать upstream за неимением такового, так что репозиторий состоит из исходного кода, <tt>.spec</tt>-файла и тривиального <tt>.gear/rules</tt>.
Если пакет разрабатывается целиком в рамках Sisyphus, то в этом случае нет необходимости отслеживать upstream за неимением такового, так что репозиторий состоит из исходного кода, {{path|.spec}}-файла и тривиального {{path|.gear/rules}}.


Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=tree ldv/packages/girar].
Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=tree ldv/packages/girar].


Типичный пример файла <tt>.gear/rules</tt>: [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=.gear/rules;hb=HEAD ldv/packages/girar/.gear/rules].
Типичный пример файла {{path|.gear/rules}}: [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=.gear/rules;hb=HEAD ldv/packages/girar/.gear/rules].


=== Репозитории с импортированным upstream-тарболами ===
== Репозитории с импортированными upstream-тарболами ==


TODO: gear-update
TODO: gear-update


==== «Линейный» репозиторий ====
=== «Линейный» репозиторий ===


Репозитории такого вида наиболее близки к первоначальному виду <tt>src.rpm</tt>, в частности создаются утилитой <tt>gear-srpmimport(1)</tt>: такие репозитории содержат дерево немодифицированного исходный кода (или несколько деревьев), набор патчей, дополнительных файлов и файл <tt>.gear/rules</tt>.
Репозитории такого вида наиболее близки к первоначальному виду <tt>src.rpm</tt>, в частности они создаются утилитой <tt>gear-srpmimport(1)</tt>. Такие репозитории содержат в одной ветке дерево (или несколько деревьев) немодифицированного исходного кода, набор патчей, дополнительных файлов, <tt>.spec</tt>-файл и файл <tt>.gear/rules</tt>.


Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=bacula.git;a=tree ldv/packages/bacula].
Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=net-tools.git;a=tree ldv/packages/net-tools].


Типичный пример файла <tt>.gear/rules</tt>: [http://git.altlinux.org/people/ldv/packages/?p=bacula.git;a=blob;f=.gear-rules;hb=HEAD ldv/packages/bacula/.gear-rules].
Типичный пример файла <tt>.gear/rules</tt>: [http://git.altlinux.org/people/ldv/packages/?p=net-tools.git;a=blob;f=.gear-rules;hb=HEAD ldv/packages/net-tools/.gear-rules].


==== Репозиторий с отдельной веткой upstream ====
=== Репозиторий с отдельной веткой upstream ===


В репозиториях такого вида обычно имеется две ветки: одна ветка хранит upstream-тарболы, импортируемые в неё с выходом каждой новой версии, во второй осуществляется пакетирование: в неё вливается ветка upstream-тарболов, в ней исправляются upstream-исходники при наличии необходимости, а также хранятся <tt>.spec</tt>-файл и <tt>.gear/rules</tt>.
В репозиториях такого вида обычно имеется две ветки: одна ветка хранит upstream-тарболы, импортируемые в неё с выходом каждой новой версии, во второй осуществляется пакетирование: в неё вливается ветка upstream-тарболов, в ней исправляются upstream-исходники при наличии необходимости, а также хранятся <tt>.spec</tt>-файл и <tt>.gear/rules</tt>.
Строка 42: Строка 41:
* если в пакет входит несколько upstream-проектов, то для каждого upstream выделяется своя ветка с тарболами.
* если в пакет входит несколько upstream-проектов, то для каждого upstream выделяется своя ветка с тарболами.


Пример пакета для нескольких веток разработки: [http://git.altlinux.org/people/ldv/packages/?p=openssl.git;a=summary ldv/packages/openssl]. Ветки <tt>master</tt> и <tt>m24</tt> служат для пакетирования для Sisyphus и Master 2.4 соответственно. Ветки <tt>openssl097</tt> и <tt>openssl098d</tt> - для упаковки других пакетов (из этого репозитория собираются пакеты <tt>openssl</tt>, <tt>openssl097</tt> и <tt>openssl098d</tt>).
Пример пакета для нескольких веток разработки: [http://git.altlinux.org/people/ldv/packages/?p=pcre.git;a=summary ldv/packages/pcre].


TODO: gear-update, gear-merge, gear-create-tag, gear-update-tag.
TODO: gear-merge, gear-create-tag, gear-update-tag.


==== Репозиторий с отдельной веткой upstream и topic-ветками ====
=== Репозиторий с отдельной веткой upstream и topic-ветками ===


В случае, когда upstream-код требует интенсивной обработки, иногда применяется схема, являющаяся развитием предыдущей. В этой схеме используется целый набор веток:
В случае, когда upstream-код требует интенсивной обработки, иногда применяется схема, являющаяся развитием предыдущей. В этой схеме используется целый набор веток:
* ветка для импортирования хранения upstream-тарболов,
* ветка для импортирования хранения upstream-тарболов,
* набор веток, в каждой из которых развивается какое-то целостное изменение (topic). Каждая из таких веток ответвляется от upstream-ветки,
* набор веток, в каждой из которых развивается какое-то целостное изменение (topic). Каждая из таких веток ответвляется от upstream-ветки,
* ветка для пакетирования. В эту ветку сливаются topic-ветки, а также в ней хранятся <tt>.spec</tt>-файл и файл <tt>.gear/rules</tt>.
* ветка для пакетирования. В эту ветку сливаются topic-ветки, а также в ней хранятся {{path|.spec}}-файл и файл {{path|.gear/rules}}.


Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=kernel-image-2.6.18.git;a=summary ldv/packages/kernel-image-2.6.18] - ветки <tt>fix-*</tt> содержат отдельные исправления, а <tt>kernel-image-ovz-smp</tt> и <tt>kernel-image-std-smp</tt> - пакетирование.
Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=kernel-image-2.6.18.git;a=summary ldv/packages/kernel-image-2.6.18] ветки {{pkg|fix-*}} содержат отдельные исправления, а {{pkg|kernel-image-ovz-smp}} и {{pkg|kernel-image-std-smp}} — пакетирование.


Аналогично предыдущей схеме, в этом случае могут присутствовать множественные upstream-ветки и ветки для пакетирования.
Аналогично предыдущей схеме, в этом случае могут присутствовать множественные upstream-ветки и ветки для пакетирования.


=== Репозитории с импортированной историей upstream ===
См. также [[Git/MergingBranches]].
 
=== Репозиторий с отдельными ветками для upstream и патчей ===
 
Этот вариант очень близок к [[Руководство по gear#Репозиторий с отдельной веткой upstream и topic-ветками|Репозиторий с отдельной веткой upstream и topic-ветками]].
 
Как для не модифицированных исходников ({{pkg|upstream}} или {{pkg|origin/master}}), так и для каждого патча ({{pkg|patches/*}}), создаётся отдельная ветка. ''(Таким образом можно легко отделить каждое изменение).'' Для пакетирования используется отдельная ветка (например, {{pkg|master}}). ''(Она не содержит код программы).''
 
Для успешной сборки нужно делать {{cmd|git merge -s ours}} использованных веток в ветку для пакетирования, и записать в {{path|.gear/rules}} например следующее:
<pre>
tar: upstream:. name=@name@
diff: upstream:. patches/alt/build:. name=@name@-alt-build.patch
</pre>
 
Пример репозитория: [http://git.altlinux.org/people/ildar/packages/?p=gnome-subtitles.git;a=tag;h=refs/tags/0.8.git_149_g56dc021-alt1 ildar/packages/gnome-subtitles]
 
 
См. также [[Git/MergingBranches#если предпочитаете держать патчи не приложенными]].
 
== Репозитории с импортированной историей upstream ==


Для большего удобства работы с upstream-исходниками и для упрощения коммуникации с upstream-разработчиками в этом виде репозиториев вместо тарболов в <tt>git</tt>-репозиторий целиком импортируется история upstream-репозитория: вместо отдельных огромных коммитов в upstream-ветку в репозитории находится полное upstream-дерево с тэгами, ветками и т.д.
Для большего удобства работы с upstream-исходниками и для упрощения коммуникации с upstream-разработчиками в этом виде репозиториев вместо тарболов в <tt>git</tt>-репозиторий целиком импортируется история upstream-репозитория: вместо отдельных огромных коммитов в upstream-ветку в репозитории находится полное upstream-дерево с тэгами, ветками и т.д.
Строка 63: Строка 81:
Пример репозитория с импортированной историей upstream (импорт из CVS): [http://git.altlinux.org/people/ldv/packages/?p=genromfs.git;a=summary ldv/packages/genromfs].
Пример репозитория с импортированной историей upstream (импорт из CVS): [http://git.altlinux.org/people/ldv/packages/?p=genromfs.git;a=summary ldv/packages/genromfs].


Пример репозитория с импортированной историей ustream (импорт из git), а также отдельными ветками для пакетирования в разные ветки разработки: [http://git.altlinux.org/people/ldv/packages/?p=git.git;a=summary ldv/packages/git].
Пример репозитория с импортированной историей upstream (импорт из git), а также отдельными ветками для пакетирования в разные ветки разработки: [http://git.altlinux.org/people/ldv/packages/?p=git.git;a=summary ldv/packages/git].
 
Пример репозитория с несколькими отдельными upstream-ветками с импортированной историей upstream: [http://git.altlinux.org/people/ldv/packages/?p=gnulib.git;a=summary ldv/packages/gnulib].


Пример репозитория с несколькими отдельными upstream-ветками с импортированной историей upstream: [http://git.altlinux.org/people/ldv/packages/?p=coreutils.git;a=summary ldv/packages/coreutils].
Конечно, в репозитории с импортированной историей upstream ничто не мешает поступать как в [[Руководство по gear#Репозиторий с отдельной веткой upstream и topic-ветками|Репозиторий с отдельной веткой upstream и topic-ветками]] или в [[Руководство по gear#Репозиторий с отдельными ветками для upstream и патчей|Репозиторий с отдельными ветками для upstream и патчей]]. (Чтобы помочь вести репозитории со своими патчами (возможно, зависимыми между собой) по таким схемам и коммуницировать с upstream существет довольно широко известная утилита topgit. Она неспецифична для maintainer-ства пакетов в дистрибутиве, а общего назначения. См. [[Git/MergingBranches#topgit]].)


TODO: засасывание исходников, конверсия репозиториев.
TODO: засасывание исходников, конверсия репозиториев.
{{Category navigation|title=gear|category=gear|sortkey={{SUBPAGENAME}}}}

Версия от 06:53, 17 июля 2015

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


Паттерны ведения пакетов в gear

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

TODO: gear-srpmimport, gear-buildreq, gear-changelog, gear-commit, gear[-remote][{,-hsh,-rpm}], gear-uupdate.

«Родной» репозиторий

Если пакет разрабатывается целиком в рамках Sisyphus, то в этом случае нет необходимости отслеживать upstream за неимением такового, так что репозиторий состоит из исходного кода, .spec-файла и тривиального .gear/rules.

Типичный пример репозитория: ldv/packages/girar.

Типичный пример файла .gear/rules: ldv/packages/girar/.gear/rules.

Репозитории с импортированными upstream-тарболами

TODO: gear-update

«Линейный» репозиторий

Репозитории такого вида наиболее близки к первоначальному виду src.rpm, в частности они создаются утилитой gear-srpmimport(1). Такие репозитории содержат в одной ветке дерево (или несколько деревьев) немодифицированного исходного кода, набор патчей, дополнительных файлов, .spec-файл и файл .gear/rules.

Типичный пример репозитория: ldv/packages/net-tools.

Типичный пример файла .gear/rules: ldv/packages/net-tools/.gear-rules.

Репозиторий с отдельной веткой upstream

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

Типичный пример репозитория: ldv/packages/bash.

Типичный пример файла .gear/rules: ldv/packages/bash/.gear/rules.

В отдельных случаях веток может быть больше двух:

  • если пакетирование производится под несколько веток разработки (Sisyphus, branches...), то каждой ветке выделяется своя git-ветка.
  • если в пакет входит несколько upstream-проектов, то для каждого upstream выделяется своя ветка с тарболами.

Пример пакета для нескольких веток разработки: ldv/packages/pcre.

TODO: gear-merge, gear-create-tag, gear-update-tag.

Репозиторий с отдельной веткой upstream и topic-ветками

В случае, когда upstream-код требует интенсивной обработки, иногда применяется схема, являющаяся развитием предыдущей. В этой схеме используется целый набор веток:

  • ветка для импортирования хранения upstream-тарболов,
  • набор веток, в каждой из которых развивается какое-то целостное изменение (topic). Каждая из таких веток ответвляется от upstream-ветки,
  • ветка для пакетирования. В эту ветку сливаются topic-ветки, а также в ней хранятся .spec-файл и файл .gear/rules.

Типичный пример репозитория: ldv/packages/kernel-image-2.6.18 — ветки fix-* содержат отдельные исправления, а kernel-image-ovz-smp и kernel-image-std-smp — пакетирование.

Аналогично предыдущей схеме, в этом случае могут присутствовать множественные upstream-ветки и ветки для пакетирования.

См. также Git/MergingBranches.

Репозиторий с отдельными ветками для upstream и патчей

Этот вариант очень близок к Репозиторий с отдельной веткой upstream и topic-ветками.

Как для не модифицированных исходников (upstream или origin/master), так и для каждого патча (patches/*), создаётся отдельная ветка. (Таким образом можно легко отделить каждое изменение). Для пакетирования используется отдельная ветка (например, master). (Она не содержит код программы).

Для успешной сборки нужно делать git merge -s ours использованных веток в ветку для пакетирования, и записать в .gear/rules например следующее:

tar: upstream:. name=@name@
diff: upstream:. patches/alt/build:. name=@name@-alt-build.patch

Пример репозитория: ildar/packages/gnome-subtitles


См. также Git/MergingBranches#если предпочитаете держать патчи не приложенными.

Репозитории с импортированной историей upstream

Для большего удобства работы с upstream-исходниками и для упрощения коммуникации с upstream-разработчиками в этом виде репозиториев вместо тарболов в git-репозиторий целиком импортируется история upstream-репозитория: вместо отдельных огромных коммитов в upstream-ветку в репозитории находится полное upstream-дерево с тэгами, ветками и т.д.

Пример репозитория с импортированной историей upstream (импорт из CVS): ldv/packages/genromfs.

Пример репозитория с импортированной историей upstream (импорт из git), а также отдельными ветками для пакетирования в разные ветки разработки: ldv/packages/git.

Пример репозитория с несколькими отдельными upstream-ветками с импортированной историей upstream: ldv/packages/gnulib.

Конечно, в репозитории с импортированной историей upstream ничто не мешает поступать как в Репозиторий с отдельной веткой upstream и topic-ветками или в Репозиторий с отдельными ветками для upstream и патчей. (Чтобы помочь вести репозитории со своими патчами (возможно, зависимыми между собой) по таким схемам и коммуницировать с upstream существет довольно широко известная утилита topgit. Она неспецифична для maintainer-ства пакетов в дистрибутиве, а общего назначения. См. Git/MergingBranches#topgit.)

TODO: засасывание исходников, конверсия репозиториев.