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

[Ed V. Bartosh]

 >> 
 >> Это другое дело. Зависимости на предоставляемое 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. Работать без зависимостей - это не наш
метод все-таки, не находишь ?

-- 
Best regards,
Ed V. Bartosh