Re: [d-kernel] kernel policy

[ed@altlinux.ru (Ed V. Bartosh)]

Hello, Anton

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

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

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

 AF> Скриптом естественно.
 AF> rpm --filesbypkg kernel-image-2.4.21pre5-std-up-2.4.21pre5-alt1|grep
 AF> modules

 AF> Далее - убираем .o и путь к модулю. Получаем базу данных ;-)
:) Грабли будут. Ладно, этот путь все равно не принимается для данного
репозитария, завязываем. Но по мне, так тут грабель просто поля будут.

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

 AF> Угумс. Тогда нужно будет соответственно отслеживать появление новых
 AF> пакетов, содержащих модули и производить пересборку kernel-image.
Да, но это уже будет решать мэнтейнер этого kernel-image.
Не хочет - не пересобирает.

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

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

-- 
Best regards,
Ed V. Bartosh