[d-kernel] script for buildling multiple kernels

[d-kernel] script for buildling multiple kernels

[Peter Novodvorsky]

Привет.

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

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

На выходе мы имеем количество flavourов по числу
subflavourов. %krelease, %kversion определяются из changelog.  config
прогоняется через cpp с опциями соответствующими
subflavourу. changelog добавляется в конец готовых спеков.

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

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

Жду комментариев.
Nidd.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [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