[d-kernel] kernel policy

[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-тра-та-та и отразить этот
факт в полиси. В случае, если такая стратегия таки будет принята.

При переходе на новую версию сборка базы - это первоочередная задача
и все все бросают и точат свои патчи под новые сорцы. Если кто-то не
может, не успевает, то его патч подделают другие, не вижу тут проблем.

 AF> Тогда нам соответственно нужна будет таблица аля
 AF> ldetect-lst, в которой будет прописано, в каких пакетах -
 AF> какие модули.
 >> Не обязательно, если включить в ядро все железо. В виде зависимостей
 >> на пакеты с драйверами, а не собирать с ядром. По возможности, конечно.

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

 >> А если гарантированно все пакеты с железом будут проставлены ?

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

 >> Все модули ? И каждый раз при обновлении какого-либо драйвера этот
 >> архив пересобирать ? И ядро пересобирать ?

 AF> Нет, ядро не пересобирать.Пересобирается модуль и генерится некий файл
 AF> с описанием какие модули есть, каких ??? версий ???. Т.е. - фактически
 AF> репозитарий драйверов.

 >> И вытаскивать/устанавливать ?

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

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


-- 
Best regards,
Ed V. Bartosh