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

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


FAQ

Q: gear: .gear/rules line 2: Name "v2.6.27.27" not found in tag list A: gear-update-tag -avc && git commit -am 'gear-update-tag'

Паттерны ведения пакетов в 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). Такие репозитории содержат в одной ветке дерево (или несколько деревьев) немодифицированного исходного кода, набор патчей, дополнительных файлов, .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-ветки и ветки для пакетирования.

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

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

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

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

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

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