[d-kernel] script for buildling multiple kernels

[Ed V. Bartosh]

Hello, Peter

 PN> У меня, как у maintainerа std и vanilla возникает дурацкая проблема
 PN> синхронизации changelogов/releaseов пакетов up и smp, а так же в
 PN> последствии возможного up-bm (bigmem). Поэтому я предлагаю сделать
 PN> скрипт, которому на вход подаётся следующее:

 PN> 1. шаблон specа, в котором УЖЕ прописаны патчи, но нет changelog,
 PN> %krelease и %kversion, а flavour определён в точности до subflavour
 PN> :). То есть не указано, up это, smp или bugmem.
 PN> 2. config для ядра, с условиями для препроцессора cpp, -- #ifdef UP,
 >> ifdef SMP, #ifdef UP-BIGMEM, и так далее. 
 PN> 3. файл с changelog.
 PN> 4. Набор subflavourов для сборки

 PN> На выходе мы имеем количество flavourов по числу
 PN> subflavourов. %krelease, %kversion определяются из changelog.  config
 PN> прогоняется через cpp с опциями соответствующими
 PN> subflavourу. changelog добавляется в конец готовых спеков.
Мне это не очень понравилось :(
Если это разные пакеты, то и Changelog у них по определению может быть
разным. Если это не так, то честнее будет вернуться к предыдущей
схеме, когда из одного спека генерилась куча ядерных .rpm

 PN> Единственная видимая мной проблема, -- maintaince config'а ядра. ведь
 PN> при обновлении, допустим, через menuconfig, всей конфигурации опции
 PN> препроцессора просто пропадут. 

 PN> Но мы знаем, что опции определяющие flavour, как то SMP или UP почти
 PN> не меняются от версии к версии, поэтому можно добавлять важные
 PN> переменные ограниченные #ifdefами в конец configа исходного конфига.
Если я правильно понял, то в результате вместо ведения Changelog-а в
каждом пакете, предлагается иметь один Changelog, зато заморачиваться
с конфигами и препроцессором ? И что мы выигрываем ?

PS:
[ed на pc213 kernel-source-2.4.21pre5]$ head -3 .config 
#
# Automatically generated by make menuconfig: don't edit
#

-- 
Best regards,
Ed V. Bartosh