Руководство по gear: различия между версиями
Нет описания правки |
(gear-update-tag(1) is misleadingly named and deprecated; looks especially funny near gear-create-tag(1)) |
||
(не показаны 3 промежуточные версии 2 участников) | |||
Строка 1: | Строка 1: | ||
[[Категория:Руководства|gear]] | [[Категория:Руководства|gear]] | ||
[[en:Gear/Introduction]] | |||
{{Stub}} | {{Stub}} | ||
Строка 43: | Строка 43: | ||
Пример пакета для нескольких веток разработки: [http://git.altlinux.org/people/ldv/packages/?p=pcre.git;a=summary ldv/packages/pcre]. | Пример пакета для нескольких веток разработки: [http://git.altlinux.org/people/ldv/packages/?p=pcre.git;a=summary ldv/packages/pcre]. | ||
TODO: gear-merge, gear-create-tag, gear- | TODO: gear-merge, gear-create-tag, gear-store-tags. | ||
=== Репозиторий с отдельной веткой upstream и topic-ветками === | === Репозиторий с отдельной веткой upstream и topic-ветками === | ||
Строка 55: | Строка 55: | ||
Аналогично предыдущей схеме, в этом случае могут присутствовать множественные upstream-ветки и ветки для пакетирования. | Аналогично предыдущей схеме, в этом случае могут присутствовать множественные upstream-ветки и ветки для пакетирования. | ||
См. также [[Git/MergingBranches]]. | |||
=== Репозиторий с отдельными ветками для upstream и патчей === | === Репозиторий с отдельными ветками для upstream и патчей === | ||
Строка 69: | Строка 71: | ||
Пример репозитория: [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] | Пример репозитория: [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 == | ||
Строка 79: | Строка 84: | ||
Пример репозитория с несколькими отдельными 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=gnulib.git;a=summary ldv/packages/gnulib]. | ||
Конечно, в репозитории с импортированной историей 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}}}} |
Текущая версия от 21:23, 27 января 2024
Паттерны ведения пакетов в 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-store-tags.
Репозиторий с отдельной веткой 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: засасывание исходников, конверсия репозиториев.