Re: [d-kernel] Re: [devel] Q: update kernel-policy

[Anton Farygin <rider@altlinux.com>]

On Thu, Jan 22, 2004 at 12:20:11PM +0200, Ed V. Bartosh wrote:
> 
>  >> 
>  >> Это другое дело. Зависимости на предоставляемое API должны быть, но
>  >> это не должны быть зависимости на модули или image. 
>  >> Это может решаться именно таким образом - модуль или ядро будут
>  >> провайдить это. Нужно только более жестко оговорить формат и внести в полиси.
> 
>  SV> В том-то и дело, что такие зависимости не решают проблемы - может
>  SV> быть установлено несколько ядер, только часть из которых
>  SV> предоставляет API.  Более того, какие-то комбинации могут вообще не
>  SV> существовать, хотя по отдельности (в разных ядрах) они есть.
> Они не решают проблему на 100%, но обеспечивают работоспособность
> пакета в принципе. Без них и этого не будет, что тоже неправильно.
> Насчет комбинаций - в большинстве случаев все-таки будет нужно одно
> API, а не несколько. Хотя, в принципе да, такая возможность есть.
> 
>  SV> А вот проблемы от этих зависимостей реально существуют.  Конечно,
>  SV> можно считать их ошибками в apt, но от этого не легче.
> 
>  SV> В документации записано, что пакеты с ядрами не обновляются
>  SV> автоматически при выполнении apt-get dist-upgrade.  Однако при
>  SV> наличии хотя бы косвенной зависимости на ядро (через provides в
>  SV> самом пакете ядра, или даже в пакете с модулями) по этим
>  SV> зависимостям вполне может вытянуться новое ядро.  Что ещё хуже,
>  SV> поскольку зависимость будет предоставляться несколькими пакетами
>  SV> (для разных вариантов ядра), apt будет выбирать один из этих пакетов
>  SV> самостоятельно - как правило, результат этого выбора никуда не
>  SV> годится.
> Эначит нужно фиксить apt. Работать без зависимостей - это не наш
> метод все-таки, не находишь ?

Правильно. Нужно фиксить apt. А еще точнее - посмотреть на Lua и
попробовать на нем реализовать недостающую функциональность для выблора
нужного ядра/пакета. Если, конечно, такое получится.

Rgds,
Rider