[d-kernel] kernel policy

[aen]

Ed V. Bartosh пишет:

>Hello, Peter
>
> n> kernel-patch-feat-%{upsteram_name}
> n> kernel-patch-fix-%{upstream_name}
> >> Предлагаю убрать patch- из названия:
> >> kernel-feat-%{upsteram_name}
> >> kernel-fix-%{upstream_name}
> >> 
> >> По-моему достаточно информативно и короче.
>
> PN> это не информативно. это не говорит, что это -- патч. Может ещё
> PN> -source- убрать?
>Дык feat и fix будут говорить о том, что это патч, если уж так оно
>надо. Только зачем, никак не пойму. Какая от этого польза знать что
>это патч ? Давайте абстрагироваться :) Я вижу пакет
>kernel-feat-security-rsback - мне обязательно знать, что это патч ?
>Зачем ?
>
>
>
> >> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
> >> или хотя бы минимизировать их количество. 
> >> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
> >> Я как-то до сих пор их не уяснил :(
>
> PN> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
> PN> src rpm. Нет, не судьба называть их kernel-module.
>По-моему сейчас строится новая схема сборки. И существующие
>пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
>успехом можно оставить старый принцип сборки ядра, опираясь на то, что
>такие ядра есть в Сизифе :) Где развитие ?
>Я не предлагаю их безоговорочно убрать. Определите принципы по которым
>будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
>представляется слабым доказательством.
>
Обе Ваши реплики в этом письме -- на одну тему. Если все "дополнения и 
исправления" -- патчи, то слово patch в имени пакета не обязательно.
Почему сохранение пакетов с модулями, которые собираются отдельно, мне 
предлставляется необходимым, я писал в прошлом письме.
Давайте обсудим.
nidd, насколько я понял, предложил принцип: все модули, не входящие в 
vanilla, которые могут быть собраны отдельно от пакета ядра, собираются 
отдельно.

Rgrds, Алексей

>  
>