[d-kernel] kernel policy

[aen]

Anton Farygin пишет:

> Ed V. Bartosh пишет:
>
>> Hello, Anton
>>  AF> Удобство эксплуатации - безусловно, важный момент. А о
>>  AF> каком удобстве _эксплуатации_ может идти речь, если
>>  AF> вместо одного пакета появляется десяток-другой ?
>> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
>> позволяет гибко комплектовать окончательные kernel-image с набором
>> нужных фич. А для юзера собственно ничего не меняется - он берет
>> понравившийся kernel-image и ставит себе. Не хочет задумываться -
>> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
>> alsa и это не повод для вытягивания нового ядра, апгрэйдится только
>> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
>> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
>> такого же плана ?
>
>
> Насколько удобно будет сборщикам собирать новые пакеты с драйверами и 
> ядра.
>
> Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс 
> сборки ядра будет выглядеть примерно так:
>
> 1) Nidd собирает kernel-source и выкладывает
> 2) Мантейнеры соответствующих патчей начинают портировать свои патчи 
> на новое ядро. До тех пор, пока все не запортируются - нет возможности 
> собрать std-sub ядро 

Нет. Патчи std собирает главный мейнтейнер ядра.

>
> 3) После портирования патчей мантейнеры ядер начинают медленно и 
> упорно собирать собственно сами ядра (не забыть, что еще нужно всем 
> владельцам пакетов kernel-feat, входящим в kernel-image 
> запортироваться на новое ядро (если есть необходимость))
>
> Лично мне не очень нравится пункт 2, ибо тогда задержка с 
> портированием хоть одного мантейнера патча или функционала будет 
> держать всех остальных. Есть идеи, как это обойти ? Может быть 
> прописать в policy, что в случае задержек мантейнер ядра имеет право 
> пересобрать пакет с функционалом? 

Да.

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

Да, я об этом писал. Не знаю только, надо ли это включать в policy.

>
>

Rgrds, Алексей