Ed V. Bartosh пишет:
> Hi,
> 
>  a> от ядра и, соотвественно, для установки новой версии пакета, собранной
>  a> с тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно,
>  a> например, в случае фиксов alsa или новых версий nvidia.
>  >> 
>  >> То есть в случае других фиксов kernel-image будет пересобираться, а в
>  >> случае фиксов alsa нет ? То есть вынесение модуля в отдельный пакет
>  >> происходит исходя из частоты его обновления, я правильно понял ?
>  >> 
>  >> 
> 
>  a> Из асинхронности его обновления с обновлением ядра. Так
>  a> как в любом случае модуль пересобрать и скачать быстрее,
>  a> то что меняется чаще -- не суть важно.
> Понятно.
> 
> Я все-таки хочу дообсуждать тему отдельных пакетов с модулями.
> Можно рассмотреть 2 схемы:
> 1 - стратегия выноса в отдельные пакеты как можно большего количества
>     функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
>     апгрэйдить на продекшен системах (без перезагрузки), можно брать и
>     ставить только тот функционал, который нужен. 
>     Минусы тоже присутствуют, основной - большое количество пакетов, 
>     ведь их нужно будет собирать под конкретные ядра.

Еще один минус - придется увязывать названия пакетов с оборудованием и 
функционалом. Ибо для правильной установки этого в программе установки 
придется немного поработать. Сейчас же устанавливается ядро, в котором 
просто все есть.

> 2 - противоположная стратегия - сборка как можно большего количества
>     модулей вместе с ядром, в составе kernel-image. Здесь с минусами и
>     плюсами все наоборот.

Я бы предложил среднее: то, что необходимо для программы установки (в 
плане функциональности) нам нужно включать в kernel-image. Все остальное 
(например freeswan) - выносить в отдельные пакеты. По мере появления 
поставляемой из коробки функциональности (а также по мере тестирования 
сторонних модулей) - переносить в базовое ядро необходимые модули.

> 
> Истина где-то между этими двумя крайностями, IMHO. 
> А вот где, неплохо бы выяснить. Кто что скажет ?
> 
> И еще: Возможно было бы пойти по первой схеме, только иметь
> некое базовое собранное ядро (без фич, только с фиксами) и пакеты
> модулей, собранных относительно этой базы.
> А окончательные kernel-image будут просто пакетами, которые будут
> составлять некие наборы из базы и модулей.
> Возможно в этом случае удалось бы избежать основных
> недостатков схемы 1.
> Давайте обсудим, считаю, что это вопрос стратегический.

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

Rgds,
Rider