Re: [devel] Build from gear

["Денис Смирнов" <mithraen@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 3394 bytes --]

On Sun, Oct 15, 2006 at 08:52:01PM +0400, Konstantin A. Lepikhov wrote:

>> Система с темплейтами модулей рулез, и она должна остаться.
>> Меня другое волнует.
>> Я правильно понимаю что ты предпчитаешь оставить пока все как есть? Идея
>> переносить kernel cvs в нынешнем виде прямо в git, боюсь, будет иметь
>> недостатков больше чем преимуществ.
KAL> я предлагаю спокойно все обдумать и предложить варианты. Вариант с
KAL> горячкой "через-2-недели-всем-трындец" меня напрягает (тут еще гоша за
KAL> спиной стоит).

Идея принимается. Сожалею что мои письма были расценены как паника.

>> Вопрос -- если я захочу завтра отправить feat с patch'o'matic, и собрать с
>> ним ядро (ну вот нужно оно под какую-либо задачу), и при этом не имею
>> доступа в kernel cvs мне что, повеситься? А обычно на такие маньячные
>> пожелания много кого есть.
KAL> я вот собрал wks26 с альтернативным dvb-v4l и не повесился. С git оно
KAL> конечно еще проще - сделал бранч и забыл.

Вот-вот.

>> Кроме того скажу ещё одну страшную штуку. Только не матюкайся,
>> В kernel git всякие fix/feat вообще нафиг не нужны. Ветки это. И
>> базироваться он должен на kernel git (нынешний процесс с экспортом из git
>> исходников мне очень напоминает закат солнца вручную). И сейчас у нас
>> сборка ядер невоспроизводима по ходу утекания Сизифа. 
KAL> это да, но собственно, тут мы с тобой едины во мнениях. Собственно, git
KAL> тут как раз и рулит.

Отлично :)

Соответственно я о чем и говорю -- как максимально эффективно можно
использовать новую платформу для этой задачи?

Если бы я знал ответ, я бы не высказывался тут, а готовые, пусть и кривые,
скрипты бы сразу на суд общественности тащил.

>> На эту проблему мне будет почти пофиг после введения gear -- мне надо, я
>> протестирую и залью сам же фикс.
>> А вот проблема что после очередной сборки php все модули, кроме
>> собирающихся из исходников php ещё могут хрен знает сколько не
>> обновляться, это проблема.
KAL> ?? А чем эта ситуация будет отличаться от вышеприведенного решения :)

Объясняю кратко.

В случае если у нас один единственный php я выкручиваюсь одним скриптом.
Которые залезет в git, сделает снапшоты, проапдейтит spec (добавив .1 в
release и добавит строчку в changelog), а потом выполнит gear-release на
результат. Скриптик пишется, ясное дело, элементарно. Все, серия пакетов
улетела на автоматическую пересборку.

В случае с системой a-la kernel cvs, когда у нас из одного спека
генерируются реальные спеки для нескольких flavour задача выглядит уже
чуток интереснее.

Хотя бы потому что для первых инфраструктура git.alt бует блокировать
потерю изменений, в случае же генерирования spec'ов у нас нет никакой
формализованой связи между оригинальным спеком и сгенерированым. Поэтому
история может (а значит и будет) теряться. Вот это не просто плохо, а
очень плохо. И конкретно эту проблему я не понимаю с какой стороны решать.

>> Ну и в завершение: в любом случае по поводу kernel cvs самое главное это
>> мнение одного человека -- Сергея. Потому что он знает git, и его
>> применение при сборке ядер лучше чем мы с тобой вместе взятые.
KAL> разные точки зрения всегда хороши.

Безусловно.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Если я не вернyсь - считайте меня программистом.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]