From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Mailer: Gnus v5.8.8/XEmacs 21.4 - "Portable Code" X-Comment-To: aen To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> <3E9C5571.2040009@altlinux.ru> <3E9D746E.5040006@altlinux.ru> In-Reply-To: <3E9D746E.5040006@altlinux.ru> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: 16 Apr 2003 18:31:06 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: devel-kernel-admin@altlinux.ru Errors-To: devel-kernel-admin@altlinux.ru X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel-kernel@altlinux.ru List-Unsubscribe: , List-Id: ALT Linux kernel packages development List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: Hi, a> от ядра и, соотвественно, для установки новой версии пакета, собранной a> с тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно, a> например, в случае фиксов alsa или новых версий nvidia. >> >> То есть в случае других фиксов kernel-image будет пересобираться, а в >> случае фиксов alsa нет ? То есть вынесение модуля в отдельный пакет >> происходит исходя из частоты его обновления, я правильно понял ? >> >> a> Из асинхронности его обновления с обновлением ядра. Так a> как в любом случае модуль пересобрать и скачать быстрее, a> то что меняется чаще -- не суть важно. Понятно. Я все-таки хочу дообсуждать тему отдельных пакетов с модулями. Можно рассмотреть 2 схемы: 1 - стратегия выноса в отдельные пакеты как можно большего количества функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще апгрэйдить на продекшен системах (без перезагрузки), можно брать и ставить только тот функционал, который нужен. Минусы тоже присутствуют, основной - большое количество пакетов, ведь их нужно будет собирать под конкретные ядра. 2 - противоположная стратегия - сборка как можно большего количества модулей вместе с ядром, в составе kernel-image. Здесь с минусами и плюсами все наоборот. Истина где-то между этими двумя крайностями, IMHO. А вот где, неплохо бы выяснить. Кто что скажет ? И еще: Возможно было бы пойти по первой схеме, только иметь некое базовое собранное ядро (без фич, только с фиксами) и пакеты модулей, собранных относительно этой базы. А окончательные kernel-image будут просто пакетами, которые будут составлять некие наборы из базы и модулей. Возможно в этом случае удалось бы избежать основных недостатков схемы 1. Давайте обсудим, считаю, что это вопрос стратегический. -- Best regards, Ed V. Bartosh