[devel] kernel packagin', new generation

[devel] kernel packagin', new generation

[Peter Novodvorsky]

Здравствуйте!

Я занимаюсь созданием новых пакетов с ядром. Поговорив в ldv, rider и
другими участниками команды мои планы по проектированию новых спеков
для ядра более-менее устаканились и я вам их и представляю.

При проектировании спека мной преследовались следующие три цели, две
конкретные и одна более абстракная:

  * Из одного spec-файла генерируется не больше одного пакета с
  образом ядра.
  * Все, что может собираться отдельно от ядра, собирается отдельно.
  * Пакет с ядром должен собираться из конструктора, из маленьких
  кусочков, причем сборка нового вида ядра не должна быть запутанным
  процессом.

Я предлагаю следующую инфраструктуру. Тарболы с исходными файлами
kernel, alsa, drm, pcmcia-cs, etc., собираются в отдельные
пакеты. Патчи тоже. Со следующей стркутурой:

kernel-source RPM:
/usr/src/kernel-source-%{version}.tar.bz2
/usr/share/kspec-tmpl/kernel-source-%{version}.spec.tmpl

alsa RPM:
/usr/src/alsa-%{version}.tar.bz2
/usr/share/kspec-tmpl/alsa-%{version}.spec.tmpl


%{patch_name}-kernel-patch RPM:
/usr/src/patches/%{patch_name}/*  /* various patch files */
/usr/src/patches/apply/%{patch_name}

Планируется сделать скрипт make-kspec. make-kspec подставляет
переменные в начало spec.tmpl'ей и генерит спеки к заданным
пакетам. Например, 

make-kspec --kver 2.4.18 --modules alsa,drm,pcmcia-cs \
           --patches grsec,reiserfs --flavour multimedia \
           --release alt1

Оно генерит четыре спека, -- для ядра, и для трех модулей определяя в
них соответствующие требующиеся переменные. Далее, как происходит
работа с патчами: для спека ядра заполняется переменная %patches,
которая будет равна аргументу --patches. В спеке, в секции %prep есть
примерно следующее

local applied_patches;

tar -jxvf %kernel_tarball
pushd kernel-source-%{kversion}
for i in `echo %patches | sed -e 's/,/\ /g'`; do
  applied_patches="$applied_patches,$i"
  %patches_dir/apply/$i --kver %{kversion} --already-applied $applied_patches
done

Из этого спека будет генерится пакет kernel-image-2.4.18-multimedia
с версией 2.4.18 и версией релиза alt1 и
kernel-headers-2.4.18-multimedia с той же версией и той же версией
релиза.

Из соответствующих модулей будут генерится:
{alsa,drm,pcmcia-cs}-2.4.18-multimedia с соответствующей версией
{alsa,drm,pcmcia-cs}  и номером релиза alt1, которые будут зависеть от
kernel-headers-2.4.18-multimedia.

Единственная проблема, которая приходит мне в голову: патчи могут
конфликтовать. Но на этот случай пакет %{name}-kernel-patch может
иметь разные варианты патчей и реагировать на аргумент
--already-applied по ситуации.


Критика желательна. Просто необходима. А так же желательно согласие по
принципиальным вопросам. :)

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

Re: [devel] kernel packagin', new generation

[Volkov Serge]

Привествую,

Возможно имеет смысл распространить данное предложение на пакеты,
которые создаются из одного архива исходных кодов, но с
разными условиями сборки и/или необходимыми патчами.
например OpenLDAP {orig, sasl, krb,}, т.е. обобщить решение этого
вопроса.

Так как будет явно указываться скрипту "make-kspec --release altN" как
будет от этого зависеть %changelog или он тоже будет как-то
заполняться автоматически. Ведь планируется собирать с определенными
патчами и модулями, которые от сборки к сборке могут меняться?


Tuesday, February 18, 2003, 1:34:57 AM, you wrote:


PN> Здравствуйте!

PN> Я занимаюсь созданием новых пакетов с ядром. Поговорив в ldv, rider и
PN> другими участниками команды мои планы по проектированию новых спеков
PN> для ядра более-менее устаканились и я вам их и представляю.

PN> При проектировании спека мной преследовались следующие три цели, две
PN> конкретные и одна более абстракная:

PN>   * Из одного spec-файла генерируется не больше одного пакета с
PN>   образом ядра.
PN>   * Все, что может собираться отдельно от ядра, собирается отдельно.
PN>   * Пакет с ядром должен собираться из конструктора, из маленьких
PN>   кусочков, причем сборка нового вида ядра не должна быть запутанным
PN>   процессом.

PN> Я предлагаю следующую инфраструктуру. Тарболы с исходными файлами
PN> kernel, alsa, drm, pcmcia-cs, etc., собираются в отдельные
PN> пакеты. Патчи тоже. Со следующей стркутурой:

PN> kernel-source RPM:
PN> /usr/src/kernel-source-%{version}.tar.bz2
PN> /usr/share/kspec-tmpl/kernel-source-%{version}.spec.tmpl

PN> alsa RPM:
PN> /usr/src/alsa-%{version}.tar.bz2
PN> /usr/share/kspec-tmpl/alsa-%{version}.spec.tmpl


PN> %{patch_name}-kernel-patch RPM:
PN> /usr/src/patches/%{patch_name}/*  /* various patch files */
PN> /usr/src/patches/apply/%{patch_name}

PN> Планируется сделать скрипт make-kspec. make-kspec подставляет
PN> переменные в начало spec.tmpl'ей и генерит спеки к заданным
PN> пакетам. Например, 

PN> make-kspec --kver 2.4.18 --modules alsa,drm,pcmcia-cs \
PN>            --patches grsec,reiserfs --flavour multimedia \
PN>            --release alt1

PN> Оно генерит четыре спека, -- для ядра, и для трех модулей определяя в
PN> них соответствующие требующиеся переменные. Далее, как происходит
PN> работа с патчами: для спека ядра заполняется переменная %patches,
PN> которая будет равна аргументу --patches. В спеке, в секции %prep есть
PN> примерно следующее

PN> local applied_patches;

PN> tar -jxvf %kernel_tarball
PN> pushd kernel-source-%{kversion}
PN> for i in `echo %patches | sed -e 's/,/\ /g'`; do
PN>   applied_patches="$applied_patches,$i"
PN>   %patches_dir/apply/$i --kver %{kversion} --already-applied $applied_patches
PN> done

PN> Из этого спека будет генерится пакет kernel-image-2.4.18-multimedia
PN> с версией 2.4.18 и версией релиза alt1 и
PN> kernel-headers-2.4.18-multimedia с той же версией и той же версией
PN> релиза.

PN> Из соответствующих модулей будут генерится:
PN> {alsa,drm,pcmcia-cs}-2.4.18-multimedia с соответствующей версией
PN> {alsa,drm,pcmcia-cs}  и номером релиза alt1, которые будут зависеть от
PN> kernel-headers-2.4.18-multimedia.

PN> Единственная проблема, которая приходит мне в голову: патчи могут
PN> конфликтовать. Но на этот случай пакет %{name}-kernel-patch может
PN> иметь разные варианты патчей и реагировать на аргумент
PN> --already-applied по ситуации.


PN> Критика желательна. Просто необходима. А так же желательно согласие по
PN> принципиальным вопросам. :)




-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

Re: [devel] kernel packagin', new generation

[Alexander Bokovoy]

Один принципиальный вопрос:

как ты видишь использование этой схемы в BTE, с полностью автоматической
сборкой пакета?


On Tue, Feb 18, 2003 at 01:34:57AM +0300, Peter Novodvorsky wrote:
> 
> Здравствуйте!
> 
> Я занимаюсь созданием новых пакетов с ядром. Поговорив в ldv, rider и
> другими участниками команды мои планы по проектированию новых спеков
> для ядра более-менее устаканились и я вам их и представляю.
> 
> При проектировании спека мной преследовались следующие три цели, две
> конкретные и одна более абстракная:
> 
>   * Из одного spec-файла генерируется не больше одного пакета с
>   образом ядра.
>   * Все, что может собираться отдельно от ядра, собирается отдельно.
>   * Пакет с ядром должен собираться из конструктора, из маленьких
>   кусочков, причем сборка нового вида ядра не должна быть запутанным
>   процессом.
> 
> Я предлагаю следующую инфраструктуру. Тарболы с исходными файлами
> kernel, alsa, drm, pcmcia-cs, etc., собираются в отдельные
> пакеты. Патчи тоже. Со следующей стркутурой:
> 
> kernel-source RPM:
> /usr/src/kernel-source-%{version}.tar.bz2
> /usr/share/kspec-tmpl/kernel-source-%{version}.spec.tmpl
> 
> alsa RPM:
> /usr/src/alsa-%{version}.tar.bz2
> /usr/share/kspec-tmpl/alsa-%{version}.spec.tmpl
> 
> 
> %{patch_name}-kernel-patch RPM:
> /usr/src/patches/%{patch_name}/*  /* various patch files */
> /usr/src/patches/apply/%{patch_name}
> 
> Планируется сделать скрипт make-kspec. make-kspec подставляет
> переменные в начало spec.tmpl'ей и генерит спеки к заданным
> пакетам. Например, 
> 
> make-kspec --kver 2.4.18 --modules alsa,drm,pcmcia-cs \
>            --patches grsec,reiserfs --flavour multimedia \
>            --release alt1
> 
> Оно генерит четыре спека, -- для ядра, и для трех модулей определяя в
> них соответствующие требующиеся переменные. Далее, как происходит
> работа с патчами: для спека ядра заполняется переменная %patches,
> которая будет равна аргументу --patches. В спеке, в секции %prep есть
> примерно следующее
> 
> local applied_patches;
> 
> tar -jxvf %kernel_tarball
> pushd kernel-source-%{kversion}
> for i in `echo %patches | sed -e 's/,/\ /g'`; do
>   applied_patches="$applied_patches,$i"
>   %patches_dir/apply/$i --kver %{kversion} --already-applied $applied_patches
> done
> 
> Из этого спека будет генерится пакет kernel-image-2.4.18-multimedia
> с версией 2.4.18 и версией релиза alt1 и
> kernel-headers-2.4.18-multimedia с той же версией и той же версией
> релиза.
> 
> Из соответствующих модулей будут генерится:
> {alsa,drm,pcmcia-cs}-2.4.18-multimedia с соответствующей версией
> {alsa,drm,pcmcia-cs}  и номером релиза alt1, которые будут зависеть от
> kernel-headers-2.4.18-multimedia.
> 
> Единственная проблема, которая приходит мне в голову: патчи могут
> конфликтовать. Но на этот случай пакет %{name}-kernel-patch может
> иметь разные варианты патчей и реагировать на аргумент
> --already-applied по ситуации.
> 
> 
> Критика желательна. Просто необходима. А так же желательно согласие по
> принципиальным вопросам. :)
> 
> -- 
> Peter Novodvorsky                             nidd@myxomop.com
>    http://people.altlinux.ru/~nidd   Deadheads, unite!
>            Kill 'em all, and let God sort 'em out
> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

-- 
/ Alexander Bokovoy
---
Trouble always comes at the wrong time.

Re: [devel] kernel packagin', new generation

[Alexey V. Lubimov]

On Tue, 18 Feb 2003 01:34:57 +0300
Peter Novodvorsky <nidd@altlinux.com> wrote:

> 
> Здравствуйте!
> 
> Я занимаюсь созданием новых пакетов с ядром. Поговорив в ldv, rider и
> другими участниками команды мои планы по проектированию новых спеков
> для ядра более-менее устаканились и я вам их и представляю.
> 
> При проектировании спека мной преследовались следующие три цели, две
> конкретные и одна более абстракная:
> 
>   * Из одного spec-файла генерируется не больше одного пакета с
>   образом ядра.
>   * Все, что может собираться отдельно от ядра, собирается отдельно.
>   * Пакет с ядром должен собираться из конструктора, из маленьких
>   кусочков, причем сборка нового вида ядра не должна быть запутанным
>   процессом.

Да, пожалуй, это уже выстрадано. :)

> Критика желательна. Просто необходима. А так же желательно согласие по
> принципиальным вопросам. :)

Выглядит замечательно. Вопросы будут только к реализации.

-- 
С уважением, Алексей Любимов avl@cad.ru

Re: [devel] kernel packagin', new generation

[Albert R. Valiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

В сообщении от 18 Февраль 2003 01:34 Peter Novodvorsky написал:
> Я предлагаю следующую инфраструктуру. Тарболы с исходными
> файлами kernel, alsa, drm, pcmcia-cs, etc., собираются в
> отдельные пакеты. Патчи тоже. Со следующей стркутурой:

по поводу патчей - я не понял, ты хочешь хранить патчи в 
отдельном srpm пакете? мое мнение - не стоит. лучше хранить 
патчи в однмо пакете, достаточно лишь добавить удобоваримые 
комментарии и упорядочить их. 

- -- 

With Best Regards, Albert R. Valiev
- ------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+UgGE7d6wAH+0KuARAhYAAJ9AWV4nk7e+yyjqviwSjhgoKPgBeACdEuf8
yp8qnU4hUxhlN/qh5gFHWkE=
=yjbz
-----END PGP SIGNATURE-----

Re: [devel] kernel packagin', new generation

[Peter Novodvorsky]

"Albert R. Valiev" <darkstar@altlinux.ru> writes:

> -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1
> В сообщении от 18 Февраль 2003 01:34 Peter Novodvorsky написал:> Я
> предлагаю следующую инфраструктуру. Тарболы с исходными> файлами
> kernel, alsa, drm, pcmcia-cs, etc., собираются в> отдельные
> пакеты. Патчи тоже. Со следующей стркутурой: 

 по поводу патчей - я не понял, ты хочешь хранить патчи в отдельном
 srpm пакете? мое мнение - не стоит. лучше хранить патчи в однмо
 пакете, достаточно лишь добавить удобоваримые комментарии и
 упорядочить их.  

Нет, каждый патч (или разумную группу патчей, например группу
маленьких фиксов от ALT) хранить в своем _RPM_. Не SRPMS, а RPM.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

Re: [devel] kernel packagin', new generation

[Aleksey Novodvorsky]

Peter Novodvorsky пишет:

>"Albert R. Valiev" <darkstar@altlinux.ru> writes:
>
>  
>
>>-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1
>>В сообщении от 18 Февраль 2003 01:34 Peter Novodvorsky написал:> Я
>>предлагаю следующую инфраструктуру. Тарболы с исходными> файлами
>>kernel, alsa, drm, pcmcia-cs, etc., собираются в> отдельные
>>пакеты. Патчи тоже. Со следующей стркутурой: 
>>    
>>
>
> по поводу патчей - я не понял, ты хочешь хранить патчи в отдельном
> srpm пакете? мое мнение - не стоит. лучше хранить патчи в однмо
> пакете, достаточно лишь добавить удобоваримые комментарии и
> упорядочить их.  
>
>Нет, каждый патч (или разумную группу патчей, например группу
>маленьких фиксов от ALT) хранить в своем _RPM_. Не SRPMS, а RPM.
>
Хм. А как они туда попадут? Из какого src.rpm?
В общем, интересно было бы посмотреть.

Rgrds, Алексей

>
>  
>

Re: [devel] kernel packagin', new generation

[rider]

On Tue, Feb 18, 2003 at 05:43:26PM +0300, Peter Novodvorsky wrote:
> "Albert R. Valiev" <darkstar@altlinux.ru> writes:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1
> > В сообщении от 18 Февраль 2003 01:34 Peter Novodvorsky написал:> Я
> > предлагаю следующую инфраструктуру. Тарболы с исходными> файлами
> > kernel, alsa, drm, pcmcia-cs, etc., собираются в> отдельные
> > пакеты. Патчи тоже. Со следующей стркутурой: 
> 
>  по поводу патчей - я не понял, ты хочешь хранить патчи в отдельном
>  srpm пакете? мое мнение - не стоит. лучше хранить патчи в однмо
>  пакете, достаточно лишь добавить удобоваримые комментарии и
>  упорядочить их.  
> 
> Нет, каждый патч (или разумную группу патчей, например группу
> маленьких фиксов от ALT) хранить в своем _RPM_. Не SRPMS, а RPM.

Да, подход интересный.

Возникающие проблемы:

1) конфликтующие патчи 
2) Противоречащие патчи
3) Порядок наложения патчей из _разных_ пакетов

И как будет идти сборка пакетов ядра в BTE ?


Rgds,
Rider

[devel] Re: kernel packagin', new generation

[Alexey Tourbin]

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

On Tue, Feb 18, 2003 at 01:34:57AM +0300, Peter Novodvorsky wrote:
> 
> Здравствуйте!

Здравствуйте.

>   * Из одного spec-файла генерируется не больше одного пакета с
>   образом ядра.

> make-kspec --kver 2.4.18 --modules alsa,drm,pcmcia-cs \
>            --patches grsec,reiserfs --flavour multimedia \
>            --release alt1

1) Чем это принципиально отличается от:

rpm -ba kernel.spec \
            --define 'kver 2.4.18' --define 'modules alsa,drm,pcmcia-cs' \
            --define 'patches grsec,reiserfs' --define 'flavour multimedia' \
            --define 'release alt1'

Иными словами, RPM уже обладает средствами параметризации.  Чем плохо
генерировать разные ядра из одного spec-файла?

2) Будут ли такие ядра подлежать автоматическому обновлению из Сизифа?
Будет ли ALT собирать все возможные комбинации ядер?  Если нет (т.е.
если ядро будет слишком custom), тогда отчасти пропадает смысл
заворачивать его в rpm.  Из преимуществ rpm остается только возможность
цивилизованно удалить пакет.  Но, мне кажется, снести ядро большого ума
не надо.  Есть ещё, правда, автоматическое переключение kernel-headers и
т.п.  В общем, непонятно.


-- 
WBR, Alexey Tourbin
BIOZAK Ltd., Russia

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

Re: [devel] Re: kernel packagin', new generation

[Peter Novodvorsky]

Привет.

Alexey Tourbin <at@turbinal.org> writes:

> On Tue, Feb 18, 2003 at 01:34:57AM +0300, Peter Novodvorsky wrote:

>>   * Из одного spec-файла генерируется не больше одного пакета с
>>   образом ядра.
>
>> make-kspec --kver 2.4.18 --modules alsa,drm,pcmcia-cs \
>>            --patches grsec,reiserfs --flavour multimedia \
>>            --release alt1

> 1) Чем это принципиально отличается от:
>
> rpm -ba kernel.spec \
>             --define 'kver 2.4.18' --define 'modules alsa,drm,pcmcia-cs' \
>             --define 'patches grsec,reiserfs' --define 'flavour multimedia' \
>             --define 'release alt1'
>
> Иными словами, RPM уже обладает средствами параметризации.  Чем плохо
> генерировать разные ядра из одного spec-файла?

Ничем. Но у make-kspec будет --help, а rpm -h будет выдавать совсем
другие фишки.

> 2) Будут ли такие ядра подлежать автоматическому обновлению из
> Сизифа? Будет ли ALT собирать все возможные комбинации ядер?  Если
> нет (т.е. если ядро будет слишком custom), тогда отчасти пропадает смысл
> заворачивать его в rpm.  Из преимуществ rpm остается только возможность
> цивилизованно удалить пакет.  Но, мне кажется, снести ядро большого ума
> не надо.  Есть ещё, правда, автоматическое переключение kernel-headers и
> т.п.  В общем, непонятно.

Я буду поддерживать лишь те ядра, которые ALT Linux Team и я лично
считаю необходимыми. Если кто-то из разработчиков вызовется
поддерживать свою сборку ядра -- отлично. Следовательно,
автоматическому обновлению подлежат лишь те ядра, которые будут в
Сизиф.

Из преимуществ самосборных ядер-пакетов остается не только цивилизованное
удаление я ядра. Например, распространение собранного ядра по другим
сайтам, тоже не очень маленькое преимущество. В общем, собранное ядро
начинает обладать свойством дистрибутивности, что с моей точки зрения
не мало.

Что таки непонятно?

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

[devel] Re: kernel packagin', new generation

[Alexey Tourbin]

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

On Tue, Feb 18, 2003 at 09:09:04PM +0300, Peter Novodvorsky wrote:
> > Иными словами, RPM уже обладает средствами параметризации.  Чем плохо
> > генерировать разные ядра из одного spec-файла?
> 
> Ничем. Но у make-kspec будет --help, а rpm -h будет выдавать совсем
> другие фишки.

Тогда make-kspec может либо выдавать help, либо запускать 
exec rpm -ba $@ 

Либо преобразуя собственные упрощенные аргументы в аргументы rpmbuild,
но смысл такой же.

> Из преимуществ самосборных ядер-пакетов остается не только цивилизованное
> удаление я ядра. Например, распространение собранного ядра по другим
> сайтам, тоже не очень маленькое преимущество. В общем, собранное ядро
> начинает обладать свойством дистрибутивности, что с моей точки зрения
> не мало.
> 
> Что таки непонятно?

Необходимость и преимущества ещё одного уровня параметризации и
промежуточных spec-файлов.

-- 
WBR, Alexey Tourbin
BIOZAK Ltd., Russia

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

Re: [devel] Re: kernel packagin', new generation

[Peter Novodvorsky]

Alexey Tourbin <at@turbinal.org> writes:

> On Tue, Feb 18, 2003 at 09:09:04PM +0300, Peter Novodvorsky wrote:
>> > Иными словами, RPM уже обладает средствами параметризации.  Чем плохо
>> > генерировать разные ядра из одного spec-файла?
>> 
>> Ничем. Но у make-kspec будет --help, а rpm -h будет выдавать совсем
>> другие фишки.
>
> Тогда make-kspec может либо выдавать help, либо запускать 
> exec rpm -ba $@ 

Именно так. Хотя в make-spec возможно будет некоторый анализ
параметров, который в самом spec при сборке делать неудобно.

>> Из преимуществ самосборных ядер-пакетов остается не только цивилизованное
>> удаление я ядра. Например, распространение собранного ядра по другим
>> сайтам, тоже не очень маленькое преимущество. В общем, собранное ядро
>> начинает обладать свойством дистрибутивности, что с моей точки зрения
>> не мало.
>> 
>> Что таки непонятно?
>
> Необходимость и преимущества ещё одного уровня параметризации и
> промежуточных spec-файлов.

Все это делается ради третьего пункта. :)

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

[devel] Re: kernel packagin', new generation

[Alexey Tourbin]

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

On Tue, Feb 18, 2003 at 09:44:06PM +0300, Peter Novodvorsky wrote:
> >> Что таки непонятно?
> >
> > Необходимость и преимущества ещё одного уровня параметризации и
> > промежуточных spec-файлов.
> 
> Все это делается ради третьего пункта. :)

И ради нашего же блага. :)  Тем не менее, если есть возможность не
усложнять конструкцию и не плодить большого числа полуфабрикатов, этой
возможностью лучше воспользоваться.  Бритва Оккама.

-- 
WBR, Alexey Tourbin
BIOZAK Ltd., Russia

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

Re: [devel] Re: kernel packagin', new generation

[rider]

On Tue, Feb 18, 2003 at 09:09:04PM +0300, Peter Novodvorsky wrote:
> 
> Привет.
> 
> Alexey Tourbin <at@turbinal.org> writes:
> 
> > On Tue, Feb 18, 2003 at 01:34:57AM +0300, Peter Novodvorsky wrote:
> 
> >>   * Из одного spec-файла генерируется не больше одного пакета с
> >>   образом ядра.
> >
> >> make-kspec --kver 2.4.18 --modules alsa,drm,pcmcia-cs \
> >>            --patches grsec,reiserfs --flavour multimedia \
> >>            --release alt1
> 
> > 1) Чем это принципиально отличается от:
> >
> > rpm -ba kernel.spec \
> >             --define 'kver 2.4.18' --define 'modules alsa,drm,pcmcia-cs' \
> >             --define 'patches grsec,reiserfs' --define 'flavour multimedia' \
> >             --define 'release alt1'
> >
> > Иными словами, RPM уже обладает средствами параметризации.  Чем плохо
> > генерировать разные ядра из одного spec-файла?
> 
> Ничем. Но у make-kspec будет --help, а rpm -h будет выдавать совсем
> другие фишки.
> 
> > 2) Будут ли такие ядра подлежать автоматическому обновлению из
> > Сизифа? Будет ли ALT собирать все возможные комбинации ядер?  Если
> > нет (т.е. если ядро будет слишком custom), тогда отчасти пропадает смысл
> > заворачивать его в rpm.  Из преимуществ rpm остается только возможность
> > цивилизованно удалить пакет.  Но, мне кажется, снести ядро большого ума
> > не надо.  Есть ещё, правда, автоматическое переключение kernel-headers и
> > т.п.  В общем, непонятно.
> 
> Я буду поддерживать лишь те ядра, которые ALT Linux Team и я лично
> считаю необходимыми. Если кто-то из разработчиков вызовется
> поддерживать свою сборку ядра -- отлично. Следовательно,
> автоматическому обновлению подлежат лишь те ядра, которые будут в
> Сизиф.
> 
> Из преимуществ самосборных ядер-пакетов остается не только цивилизованное
> удаление я ядра. Например, распространение собранного ядра по другим
> сайтам, тоже не очень маленькое преимущество. В общем, собранное ядро
> начинает обладать свойством дистрибутивности, что с моей точки зрения
> не мало.
> 
> Что таки непонятно?

Можно услышать информацию о том, какие патчи предполагается накладывать на
ядра, идущие в дистрибутивы по умолчанию?

Т.е. - какая будет политика в ядре? Новые фичи или повышение стабильности?

Как будут классифицироваться патчи и какие есть идеи по
классификации/технологии храниения и именования патчей?


Rgds,
Rider

Re: [devel] Re: kernel packagin', new generation

[Peter Novodvorsky]

rider@altlinux.com writes:

> On Tue, Feb 18, 2003 at 09:09:04PM +0300, Peter Novodvorsky wrote:
>
> Можно услышать информацию о том, какие патчи предполагается накладывать на
> ядра, идущие в дистрибутивы по умолчанию?

будет несколько flavourов ядер: server, workstation, cutting-edge
(можно по короче назвать), возможно еще redhat и suse.

на server будут накладываться всякие SCSI и security патчи. в
workstation _стабильные_ (оттестированые) патчи для multimedia, ide,
preemptible. в cutting-edge будет свалка разных супер-пупер патчей,
работать оно будет соответственно. redhat и suse -- это ядра собранные
_только_ с патчами ядер соответствующих
производителей. Соответственно, предпологается, что эти ядра будут
совместимы с дистрибутивом.

> Т.е. - какая будет политика в ядре? Новые фичи или повышение
> стабильности?

server и workstation будут оставаться стабильными. Новые фичи будут
добавляться в cutting-edge и мигрировать в
server/workstation. Количество патчей налагаемых на server/workstation
предпологается сохранять минимальным, насколько это можно.

> Как будут классифицироваться патчи и какие есть идеи по
> классификации/технологии храниения и именования патчей?

Не совсем понял вопроса. Патчи будут храниться в пакетах, по группам.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

Re: [devel] Re: kernel packagin', new generation

[Denis Ovsienko]

> будет несколько flavourов ядер: server, workstation, cutting-edge
> (можно по короче назвать), возможно еще redhat и suse.
Я предлагаю ещё завести flavour "router" как минимум со следующими
опциями:
IGMP
multicast routing
large routing tables
rtnetlink
по максимуму iptables + QoS
bridging
+ подкрутить shed.c на предмет более точного разброса
пакетов по очередям (по умолчанию там не лучший выбор для маршрутизатора,
задаётся только при компиляции)
+ console on serial line, если ещё не включено
Возможно, я что-то забыл, но общий характер сборки ясен. Как нетрудно
догадаться, ядро ориентировано исключительно на маршрутизаторы ---
немаловажный сектор ALTLinux-инсталляций.


    ДонНТУ Информационный центр
    Денис Овсиенко
    DO4-UANIC

Re: [devel] Re: kernel packagin', new generation

[Peter Novodvorsky]

Привет.

Denis Ovsienko <pilot@dgtu.donetsk.ua> writes:

>> будет несколько flavourов ядер: server, workstation, cutting-edge
>> (можно по короче назвать), возможно еще redhat и suse.
> Я предлагаю ещё завести flavour "router" как минимум со следующими
> опциями:
> IGMP
> multicast routing
> large routing tables
> rtnetlink
> по максимуму iptables + QoS
> bridging
> + подкрутить shed.c на предмет более точного разброса
> пакетов по очередям (по умолчанию там не лучший выбор для маршрутизатора,
> задаётся только при компиляции)
> + console on serial line, если ещё не включено
> Возможно, я что-то забыл, но общий характер сборки ясен. Как нетрудно
> догадаться, ядро ориентировано исключительно на маршрутизаторы ---
> немаловажный сектор ALTLinux-инсталляций.

Отлично. Я собственно и делаю эту штуку, чтобы обычные разработчики
из ALT Linux Team могли поддерживать свои версии ядер.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

[devel] Re: kernel packagin', new generation

[Mikhail Zabaluev]

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

Hello Peter,

On Wed, Feb 19, 2003 at 05:23:16PM +0300, Peter Novodvorsky wrote:
>
> rider@altlinux.com writes:
> 
> > On Tue, Feb 18, 2003 at 09:09:04PM +0300, Peter Novodvorsky wrote:
> >
> > Можно услышать информацию о том, какие патчи предполагается накладывать на
> > ядра, идущие в дистрибутивы по умолчанию?
> 
> будет несколько flavourов ядер: server, workstation, cutting-edge
> (можно по короче назвать), возможно еще redhat и suse.
> 
> на server будут накладываться всякие SCSI и security патчи. в
> workstation _стабильные_ (оттестированые) патчи для multimedia, ide,
> preemptible. в cutting-edge будет свалка разных супер-пупер патчей,
> работать оно будет соответственно. redhat и suse -- это ядра собранные
> _только_ с патчами ядер соответствующих
> производителей. Соответственно, предпологается, что эти ядра будут
> совместимы с дистрибутивом.

А этого никак нельзя добиться в одном spec, используя препроцессор в RPM --
с --enable и т.д?

> > Т.е. - какая будет политика в ядре? Новые фичи или повышение
> > стабильности?
> 
> server и workstation будут оставаться стабильными. Новые фичи будут
> добавляться в cutting-edge и мигрировать в
> server/workstation. Количество патчей налагаемых на server/workstation
> предпологается сохранять минимальным, насколько это можно.

Угу. Хорошо бы к каждому набору патчей декларацию,
за что тот отвечает. Обоснование, так сказать,
увеличения дистанции от vanilla-ядра. Ну, или там
ядра SuSe, если танцуется действительно от него.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
When you make your mark in the world, watch out for guys with erasers.
		-- The Wall Street Journal

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