Ed V. Bartosh пишет:
> Hello,
> 
>  >> Можно рассмотреть 2 схемы:
>  >> 1 - стратегия выноса в отдельные пакеты как можно большего количества
>  >> функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
>  >> апгрэйдить на продекшен системах (без перезагрузки), можно брать и
>  >> ставить только тот функционал, который нужен.
>  >> Минусы тоже присутствуют, основной - большое количество
>  >> пакетов,     ведь их нужно будет собирать под
>  >> конкретные ядра.
> 
>  AF> Еще один минус - придется увязывать названия пакетов с
>  AF> оборудованием и функционалом. Ибо для правильной
>  AF> установки этого в программе установки придется немного
>  AF> поработать. Сейчас же устанавливается ядро, в котором
>  AF> просто все есть.
> Инсталлятор - это, конечно, важный элемент дистрибутива, но я бы не стал
> привязываться к нему в данном вопросе. Гораздо важнее удобство
> эксплуатации ядерных пакетов. Инсталлятор - это ведь только начало, да
> и поправить его в нужную сторону проще, чем потом иметь проблемы с остальным.

Удобство эксплуатации - безусловно, важный момент. А о каком удобстве 
_эксплуатации_ может идти речь, если вместо одного пакета появляется 
десяток-другой ?

Пример: у меня есть некая железка, неизвестного производителя. lspci 
сказал, что для нее неплохо было бы использовать драйвер noname.o, 
которого в стандартном ядре не оказалось. Вопрос - где искать этот драйвер?

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

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

Тогда нам соответственно нужна будет таблица аля ldetect-lst, в которой 
будет прописано, в каких пакетах - какие модули.

Необходимо будет поправить kudzu и инсталятор от MDK на предмет 
использования этой таблицы при определении устройств и установке пакетов.

kudzu придется править достаточно сильно.

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

Все модули идут не в пакете, а просто в архиве. Устанавливается не 
пакет, а конкретный модуль, необходимый для поддержки устройства или 
функциональности. Делается это достаточно простым скриптом.

Rgds,
Rider


P.S.
Просьба не забывать о готовящейся версии Junior 2.3