Руководство по gear

Паттерны ведения пакетов в 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.

ИЛИ

развернуть

Пример репозитория

sysmontask
├── .gear
│   └── rules
├── .git
├── sysmontask
│   ├── AUTHORS
│   ├── com.github.camelneeraj.sysmontask.gschema.xml
│   ├── debian
│   ├── DOCS.md
│   ├── glade_files
│   ├── HISTORY.md
│   ├── icons
│   ├── LICENSE
│   ├── MANIFEST.in
│   ├── README.md
│   ├── requirements.md
│   ├── setup.py
│   ├── sysmontask
│   │   ├── cpu.py
│   │   ├── disk.py
│   │   ├── filter_prefs.py
│   │   ├── gi_composites.py
│   │   ├── gproc.py
│   │   ├── gpu.py
│   │   ├── __init__.py
│   │   ├── log_plotter.py
│   │   ├── mem.py
│   │   ├── net.py
│   │   ├── proc-kill.sh
│   │   ├── rooter_default.py
│   │   ├── rooter.py
│   │   ├── sidepane.py
│   │   ├── sysmontask.py
│   │   └── theme_setter.py
│   ├── SysMonTask.desktop
│   └── uninstall.sh
└── sysmontask.spec

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

ИЛИ

развернуть

Пример .gear/rules

tar.gz: sysmontask

Репозитории с импортированными 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:

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