Ed V. Bartosh пишет:
> 
>  AF> Вот такое разбиение, например, для начала:
> 
>  AF> kernel-patches-new-drivers - содержит новые драйвера
>  AF> kernel-patches-bugfixes-drivers - содержит исправления для
>  AF> существующих драйверов
> 
>  AF> kernel-patches-security - включает в себя secrurity-fixes
>  AF> kernel-patches-update-drivers - содержит в себе обновления для
>  AF> драйверов до новых версий.
> 
>  AF> далее по такому-же принципу ;-)
> 
>  AF> Т.е. - бить или нет по категориям я бы не стал. По моему с железом все
>  AF> достаточно прозрачно и если патч не вносит изменения никуда, кроме
>  AF> кода самого драйвера - то его вполне можно включать всегда.
> Зачем так зажимать схему ? Это вариант, противоположный вынесению
> каждого патча в отдельный пакет. Я считаю, что нужен компромисс, то
> есть в данном случае все-таки группировка по категориям.
> Если мне, например, не нужны патчи, касающиеся видео, или, скажем
> ide, то я и не буду их прикладывать. Тем более, что частенько они
> правят не только свой код.
> Мне кажется, что некая гибкость в этом деле не помешает.
> 
> Предлагаю для железных патчей категории по принципу схемы 
> каталогов в сорцах:
> kernel-patches-drivers-net
> kernel-patches-drivers-scsi
> kernel-patches-drivers-ide
> kernel-patches-net
> kernel-patches-fs
> 
> И подкатегории fixes, updates, new, как Вы предлагаете.
> 
> Точно так же можно поступить и с остальными, зачем велосипед
> изобретать, если в ядре уже есть устоявшаяся иерархия.

Хм... наверное это правильно - идти по иерархии в ядре, но как быть с 
особо тяжелыми случаями, когда необходимо наложить часть патчей на scsi 
и часть патчей на net ?

Или особо тяжелые случаи - в морг ? ;-)

Rgds,
Rider