[devel] логика "менеджмента" gear+git.alt

[Damir Shayhutdinov]

>         Уважаемый Дамир!
> спасибо, что уделили мне столько времени!
:) На здоровье!

> За последний месяц я посвятил значительное количество времени, чтобы
> перейти на gear+git.alt. Я прочёл всё, что нашёл на тему
> git+gear+git.alt . Однако не наткнулся на то, какая логика
> "менеджмента" всего этого хозяйства (никто не поделился?) или, по
> крайней мере, не смог собрать из кусочков целостной картины. Ваше
> письмо очень ценно именно поэтому. Ещё раз огромное спасибо. Буду
> разбираться.
На самом деле, мантейнеры, использующие git.alt, на мой взгляд еще
только подходят к выработке этой самой целостной картины. Меня git.alt
привлекает не столько удобством, сколько широчайшим простором для
экспериментов, обсуждений, исследований. В git.alt пока еще не
оформились тренды, не определились гуру, не выработана "единая линия
партии". :)

То, что я ранее представил - это, по моему мнению, наилучшая схема
сохранения "первозданности" в условиях импорта исходников не из
тарболов астрима, а напрямую из апстримного SCM. Не исключено, что у
других мантейнеров есть какие-то собственные know-how.


> Одно пожелание: Я сейчас буду лезть в Вашу папку git/people. Не
> присоветуете мне небольшой образцово-показательный репо?
Хмм.. Ну даже не знаю что именно посоветовать. У меня там полный
зоопарк из различных схем. По дате создания репозиториев можно даже
определить "гитологические эры" - например эра gear-srpmimport, потом
эра самописных скриптов конвертации из апстримного SCM, потом вот
новая схема.

Даже внутри одного репозитория может наблюдаться смена этих эпох. :)

Хотя вот по отдельным вопросам могу посоветовать следующее:

liblazy.git - это пример использования апстримного SCM (git), когда
апстрим импортируется в отдельную ветку (upstream) без директории
верхнего уровня, в ветке master кладется spec, .gear-rules и
.gear-tags. Это свеженький пакет, я его еще не залил в Сизиф, пока
испытываю на своей машине.

KoLmafia.git - классический пример эпохи самописных скриптов. Я
написал специальный скрипт - замену git-svn, который бы складывал
импортированные исходники в директорию верхнего уровня. На этом
репозитории можно увидеть схему "много веток-патчей", и как я с ними
управляюсь. Совсем недавно например я решал проблему с конфликтом,
возникшем между апстримной веткой и патчем-веткой от raorn на . Также в
этом репозитории можно увидеть пример совместной работы мантейнеров
(для этого надо бы еще посмотреть
git.alt:/people/raorn/packages/KoLmafia.git

firebird.git - смешанная схема. В ветку upstream я кладу распакованные
тарболы, каждый помечая своим тегом. От этой ветки я отпочковал ветку
alt/system-libicu, в которой запатчил firebird на сборку с системной
libicu. И .gear-rules в master это отражает. Но этот пакет еще не
доделан.

Ну остальные я пока не рекомендую смотреть - они в основном сделаны по
минимальной схеме  а-ля git-srpmimport.

> > Я не совсем понимаю ваш стиль использования gear.
> > Мой стиль основывается на том, что в результирующем .src.rpm
> > сохраняется "замещающая первозданность(ванильность)". То есть можно
> > заменить тарбол из сгенерированного .src.rpm на тарбол из апстрима и
> > при этом ничего не изменится.
> Мне нравится.
>
> Один вопрос: Если в истории есть и тарболы, и SVN, как быть с
> исчезающими и появляющимися Makefile.in/configure ?
Просто. В спеке перед %configure ставить autoreconf -fisv
Если этих файлов не было (в случае импорта из апстрима), то они будут
созданы. Если же они были - то они будут выкинуты, и вместо них будут
созданы новые.

> > > Правильно?
> > Ну может и правильно, для вашей схемы.
> нет, не буду я таким образом... Лучше, как у Вас.. если не возникнет
> чего непредвиденного.
Ну, попробуйте, поэкспериментируйте.