[d-kernel] I: new packages to sisyphus
Anton Farygin
rider at altlinux.com
Thu Jul 31 14:09:19 MSD 2003
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 252 bytes
Desc: not available
Url : /pipermail/devel-kernel/attachments/20030731/5742faf4/attachment-0002.bin
More information about the devel-kernel
mailing list