Ed V. Bartosh пишет:
> Hello, Anton
> 
>  >> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
>  >> позволяет гибко комплектовать окончательные kernel-image с набором
>  >> нужных фич. А для юзера собственно ничего не меняется - он берет
>  >> понравившийся kernel-image и ставит себе. Не хочет задумываться -
>  >> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
>  >> alsa и это не повод для вытягивания нового ядра, апгрэйдится только
>  >> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
>  >> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
>  >> такого же плана ?
> 
>  AF> Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра.
> Не знаю. Нужно попробовать. Но, вообще, для тех драйверов, которые
> выкладываются производителями железа как раз такой подход и является
> более прямым, их приходится точить для сборки в составе ядра.

Да, для сторонних драйверов удобнее безусловно будет собирать. Проблемы 
будут возникать со сборкой новых версий основных ядер. Вопрос: будут ли 
в репозитарии жить ядра разных версий (и должны ли?)

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

> 
>  AF> Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс
>  AF> сборки ядра будет выглядеть примерно так:
> 
>  AF> 1) Nidd собирает kernel-source и выкладывает
>  AF> 2) Мантейнеры соответствующих патчей начинают портировать свои патчи
>  AF> на новое ядро. До тех пор, пока все не запортируются - нет возможности
>  AF> собрать std-sub ядро
> Предлагаю назвать его kernel-image-common-тра-та-та и отразить этот
> факт в полиси. В случае, если такая стратегия таки будет принята.
> 
> При переходе на новую версию сборка базы - это первоочередная задача
> и все все бросают и точат свои патчи под новые сорцы. Если кто-то не
> может, не успевает, то его патч подделают другие, не вижу тут проблем.

ok. Только все-таки это лучше внести в правила, что бы потом без обид ;-)

>  AF> ставить только те пакеты с драйверами, которые необходимы. Собственно
>  AF> в инсталяторе есть сейчас такая штука, но она реализована в виде хаков
>  AF> (прямо прописаны какие пакеты устанавливать если есть потребность в
>  AF> определенном драйвере). Но от таблицы я бы не отказался - будет
>  AF> хороший помошник для авторов kernel-image.
> Возможно это и так. Но у меня пока нет идей как это грамотно сделать.

Скриптом естественно.
  rpm --filesbypkg kernel-image-2.4.21pre5-std-up-2.4.21pre5-alt1|grep 
modules
Далее - убираем .o и путь к модулю. Получаем базу данных ;-)

> 
>  >> А если гарантированно все пакеты с железом будут проставлены ?
> 
>  AF> Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный
>  AF> пакет будет ставить все пакеты с железом и как сделать так, что бы все
>  AF> пакеты с железом пападали в список зависимостей у виртуального
>  AF> пакета. Желательно - автоматически ;-)
> Можно. По названиям пакетов. Полуавтоматически :)

Угумс. Тогда нужно будет соответственно отслеживать появление новых 
пакетов, содержащих модули и производить пересборку kernel-image.

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

ну это просто ;-)

> 
>  AF> По поводу репозитария драйверов - это мысли вслух. Просьба тем, кто
>  AF> считает это бредом - не комментировать. И так ясно, что  этот путь
>  AF> сложен и необычен. Это как бы предложение по улучшению текущей
>  AF> структуры.
> Если не дробить столь мелко, то такой репозиторий - это все пакеты
> kernel-module-drivers-... Чем плохо ?

В принципе без разницы. Но тогда нам нужно будет подробить помельче... 
;-) Например: драйвера по производителям kernel-drivers-net-intel, 
kernel-drivers-scsi-megaraid и т.д.

С дроблением замучаемся. ;-) Т.е. - получается двойная работа: 1) 
дробление kernel-image на мелкие пакеты 2) прописывание зависимостей 3) 
ведение базы <модуль> ->  <пакет>

Rgds,
Rider