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

[Anton Farygin <rider@altlinux.com>]

On Fri, Jan 23, 2004 at 05:41:34AM +0200, Denis Ovsienko wrote:
> 
> >  >> Это другое дело. Зависимости на предоставляемое API должны быть, но
> >  >> это не должны быть зависимости на модули или image.
> >  >> Это может решаться именно таким образом - модуль или ядро будут
> >  >> провайдить это. Нужно только более жестко оговорить формат и внести в полиси.
> Оригинального автора этих строк я так и не нашёл, поэтому отвечаю тому, у
> кого они появились впервые: я предлагал это сделать в августе или июле
> применительно к CryptoAPI и EVMS. Предлагалось примерно следующее:
> Provides: cryptoapi-kernelfeature
> Provides: evms-kernelfeature
> Provides: multicast-kernelfeature
> Естественно, только в случае наложения соответствующих патчей и/или
> включения нужных пунктов в конфиге ядра, с которым конкретный flavor
> собирался. Попытаюсь сформулировать:
> ===
> Если функциональность <name> ядра, от которой зависит
> работоспособность других userspace пакетов, предоставляется не отдельным
> пакетом kernel-modules, на который можно было бы указать зависимость, то
> такое ядро должно предоставлять тэг <name>-kernelfeature, который и будет
> прописываться в Requires соответствующим пакетам.
> ===
> Кстати, разбег версий freeswan в ядре и в userspace можно было бы таким
> образом ограничить.
> Я думаю, это было бы правильно.

Нет, ибо apt заколбасит от этого дела - при попытке поставить любой пакет,
требующий cryptoapi-kernelfeathure будет поставлено первое по алфавиту
ядро.

Rgds,
Rider