Re: [d-kernel] I: new packages to sisyphus

[Anton Farygin <rider@altlinux.com>]

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

Ed V. Bartosh пишет:
>>>>>>"AF" == Anton Farygin writes:
> 
> 
>  >>   ARV>  c8b4ca3389c7859a6a4de0efb2cea2c9
>  >>   ARV>  kernel-feat-drivers-net-3c90x-2003.07.30-alt1.src.rpm
>  >>   ARV>  Драйвер для карт 3COM 3x90x
>  >>    darkstar-alt> ed_: привет!
>  >>  darkstar-alt> ed_: по поводу 3c90x - а зачем его в отдельный
>  >>  darkstar-alt> пакет?  ed_: ему лучше всего в основном ядре жить
>  >>  darkstar-alt> ))) >> Ему лучше жить в kernel-module и
>  >>  darkstar-alt> апгрейдиться отдельно от ядра.  >> По-моему это уже
>  >>  darkstar-alt> обсуждалось и неоднократно.
>  >>
>   
>  AF>  А зачем ?
>   
>  AF>  Давайте представим себе труд мантейнера ядра, которому нужно
>  AF>  собрать новую версию пакета kernel-image:
>   
>  AF>  1) Собирает kernel-source 
> Не помню когда я делал это последний раз.
> 
> 2) Собирает kernel-image, ставит в
>  AF>  сборочную систему хедеры 3) Пересобирает 15-20 пакетов с
>  AF>  модулями, одновременно правя спеки, прописывая зависимости на
>  AF>  новое ядро и т.д.  
> Это просто нужно автоматизировать, вот и все.
> 
>  AF>  Мне откровенно жаль этого мантейнера.
> мне тоже, если это делать руками. Никто же не спорит о необходимости
> этот процесс автоматизировать.
>   
>  AF>  По моему изначально мы некоторое время обсуждали следущую
>  AF>  идеологию:
>   
>  AF>  1) Есть std ядро, включающее в себя все что мы считаем стабильно
>  AF>  работающим. Как то: дополнительные драйвера, исправления ошибок,
>  AF>  файловые системы и т.д.  2) Все остальные пакеты, дополняющие
>  AF>  или изменяющие функциональность в std-up ядре базируются
>  AF>  исключительно на нем и на его наборе патчей. Как-то w4l, rsbac,
>  AF>  ядра с supermount и т.д.
>   
>  AF>  По моему - будет намного удобнее и менее запутаннее чем в
>  AF>  текущей ситуации... Единственное что нам нужно сделать - это
>  AF>  добится максимально качественного std-up ядра.
> По-моему мы также обсуждали преимущества подхода, при котором мы имеем
> как можно больше функционала в отдельных пакетах с модулями. И особых
> возражений не было. Он имеет как минимум 2 достоинства: не нужно
> пересобирать ядро при изменениях в этих пакетах, либо добавлении новых
> и не нужно перегружать систему при их установке/апгрейде.
> Для серверных конфигураций это очень важно.  

Бесспорно.

Но прежде чем это делать - давайте автоматизируем процесс сборки?

Инсталятор похоже придется править... там сейчас есть куски кода, 
которые определяют оборудование и ставят нужные пакеты для этого 
оборудования. Но вся проблема в том, что имена пакетов вшиваются в код. ;-(

> 
> Я предлагаю таки доопределиться со стратегией выноса в модули и
> зафиксировать ее в полиси.
> 

Да.

Rgds,
Rider

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