Руководство по gear: различия между версиями
(Новая: Категория:Sisyphus Категория:Devel Категория:Руководства {{Stub}} == Паттерны ведения пакетов в <tt>gear</tt> ==...) |
Нет описания правки |
||
Строка 6: | Строка 6: | ||
== Паттерны ведения пакетов в <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}] | ||
== "Родной" репозиторий == | |||
Если пакет разрабатывается целиком в рамках Sisyphus, то в этом случае нет необходимости отслеживать upstream за неимением такового, так что репозиторий состоит из исходного кода, <tt>.spec</tt>-файла и тривиального <tt>.gear/rules</tt>. | Если пакет разрабатывается целиком в рамках Sisyphus, то в этом случае нет необходимости отслеживать upstream за неимением такового, так что репозиторий состоит из исходного кода, <tt>.spec</tt>-файла и тривиального <tt>.gear/rules</tt>. | ||
Строка 18: | Строка 18: | ||
Типичный пример файла <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]. | Типичный пример файла <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]. | ||
== Репозитории с импортированным 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>.gear/rules</tt>. | ||
Строка 30: | Строка 30: | ||
Типичный пример файла <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=bacula.git;a=blob;f=.gear-rules;hb=HEAD ldv/packages/bacula/.gear-rules]. | ||
=== Репозиторий с отдельной веткой upstream === | |||
В репозиториях такого вида обычно имеется две ветки: одна ветка хранит upstream-тарболы, импортируемые в неё с выходом каждой новой версии, во второй осуществляется пакетирование: в неё вливается ветка upstream-тарболов, в ней исправляются upstream-исходники при наличии необходимости, а также хранятся <tt>.spec</tt>-файл и <tt>.gear/rules</tt>. | В репозиториях такого вида обычно имеется две ветки: одна ветка хранит upstream-тарболы, импортируемые в неё с выходом каждой новой версии, во второй осуществляется пакетирование: в неё вливается ветка upstream-тарболов, в ней исправляются upstream-исходники при наличии необходимости, а также хранятся <tt>.spec</tt>-файл и <tt>.gear/rules</tt>. | ||
Строка 46: | Строка 46: | ||
TODO: gear-update, gear-merge, gear-create-tag, gear-update-tag. | TODO: gear-update, gear-merge, gear-create-tag, gear-update-tag. | ||
=== Репозиторий с отдельной веткой upstream и topic-ветками === | |||
В случае, когда upstream-код требует интенсивной обработки, иногда применяется схема, являющаяся развитием предыдущей. В этой схеме используется целый набор веток: | В случае, когда upstream-код требует интенсивной обработки, иногда применяется схема, являющаяся развитием предыдущей. В этой схеме используется целый набор веток: | ||
Строка 57: | Строка 57: | ||
Аналогично предыдущей схеме, в этом случае могут присутствовать множественные upstream-ветки и ветки для пакетирования. | Аналогично предыдущей схеме, в этом случае могут присутствовать множественные upstream-ветки и ветки для пакетирования. | ||
== Репозитории с импортированной историей upstream == | |||
Для большего удобства работы с upstream-исходниками и для упрощения коммуникации с upstream-разработчиками в этом виде репозиториев вместо тарболов в <tt>git</tt>-репозиторий целиком импортируется история upstream-репозитория: вместо отдельных огромных коммитов в upstream-ветку в репозитории находится полное upstream-дерево с тэгами, ветками и т.д. | Для большего удобства работы с upstream-исходниками и для упрощения коммуникации с upstream-разработчиками в этом виде репозиториев вместо тарболов в <tt>git</tt>-репозиторий целиком импортируется история upstream-репозитория: вместо отдельных огромных коммитов в upstream-ветку в репозитории находится полное upstream-дерево с тэгами, ветками и т.д. |
Версия от 07:02, 21 августа 2008
Паттерны ведения пакетов в gear
gear спроектирован для сборки пакетов из произвольно устроенного git-репозитория, но при этом среди gear-репозиториев наиболее часто встречаются следующие варианты.
TODO: gear-srpmimport, gear-buildreq, gear-changelog, gear-commit, gear[-remote][{,-hsh,-rpm}]
"Родной" репозиторий
Если пакет разрабатывается целиком в рамках Sisyphus, то в этом случае нет необходимости отслеживать upstream за неимением такового, так что репозиторий состоит из исходного кода, .spec-файла и тривиального .gear/rules.
Типичный пример репозитория: ldv/packages/girar.
Типичный пример файла .gear/rules: ldv/packages/girar/.gear/rules.
Репозитории с импортированным upstream-тарболами
TODO: gear-update
«Линейный» репозиторий
Репозитории такого вида наиболее близки к первоначальному виду src.rpm, в частности создаются утилитой gear-srpmimport(1): такие репозитории содержат дерево немодифицированного исходный кода (или несколько деревьев), набор патчей, дополнительных файлов и файл .gear/rules.
Типичный пример репозитория: ldv/packages/bacula.
Типичный пример файла .gear/rules: ldv/packages/bacula/.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/openssl. Ветки master и m24 служат для пакетирования для Sisyphus и Master 2.4 соответственно. Ветки openssl097 и openssl098d - для упаковки других пакетов (из этого репозитория собираются пакеты openssl, openssl097 и openssl098d).
TODO: gear-update, 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-ветки и ветки для пакетирования.
Репозитории с импортированной историей upstream
Для большего удобства работы с upstream-исходниками и для упрощения коммуникации с upstream-разработчиками в этом виде репозиториев вместо тарболов в git-репозиторий целиком импортируется история upstream-репозитория: вместо отдельных огромных коммитов в upstream-ветку в репозитории находится полное upstream-дерево с тэгами, ветками и т.д.
Пример репозитория с импортированной историей upstream (импорт из CVS): ldv/packages/genromfs.
Пример репозитория с импортированной историей ustream (импорт из git), а также отдельными ветками для пакетирования в разные ветки разработки: ldv/packages/git.
Пример репозитория с несколькими отдельными upstream-ветками с импортированной историей upstream: ldv/packages/coreutils.
TODO: засасывание исходников, конверсия репозиториев.