From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Comment-To: Anton Farygin To: ALT Devel discussion list Subject: Re: [d-kernel] Re: [devel] Q: update kernel-policy In-Reply-To: <20040122074341.GO23904@master.altlinux.ru> (Anton Farygin's message of "Thu, 22 Jan 2004 10:43:41 +0300") References: <20040121164043.GA2114@basalt.office.altlinux.org> <20040122061853.R86035@elefant.dgtu.donetsk.ua> <20040122074341.GO23904@master.altlinux.ru> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Thu, 22 Jan 2004 11:51:11 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: ALT Linux kernel packages development X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2004 09:51:13 -0000 Archived-At: List-Archive: List-Post: >>>>> "AF" == Anton Farygin writes: AF> On Thu, Jan 22, 2004 at 06:24:49AM +0200, Denis Ovsienko wrote: >> > 1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и > >> kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида > >> kernel-image-XXX и kernel-modules-XXX. Почему же? В модулях >> может быть какое-то API, без которого userspace пакет будет >> бесполезным. Или в ядре. Я уже который раз прошу промаркировать >> соответствующие ядра как cryptoapi-kernel, но меня игнорируют, >> поэтому что остаётся делать? AF> Пока не понятно, как привязывать userspace к kernelspace, ибо AF> пакетов с ядрами может стоять _огромное количество_, а реальное AF> ядро - совсем не совпадать с тем, что установлено. Есть такое дело. Но привязывать все равно нужно. Если будет установлено хотя бы одно ядро или модуль, который провайдит нужное API, то это уже в принципе обеспечивает работу юзерспейса. Да, есть еще дополнительные условия, которые нужно обеспечить, но это все равно гораздо лучше, чем не иметь таких зависимостей вовсе и как следствие не иметь даже принципиальной возможности работы поставленного пакета. -- Best regards, Ed V. Bartosh