From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3E9E4517.3070500@altlinux.com> Date: Thu, 17 Apr 2003 10:09:27 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030210 X-Accept-Language: ru-ru, en MIME-Version: 1.0 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: X-Enigmail-Version: 0.70.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6665E802BBDC1EC307FC6298" 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: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6665E802BBDC1EC307FC6298 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Ed V. Bartosh пишет: > Hi, > > a> от ядра и, соотвественно, для установки новой версии пакета, собранной > a> с тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно, > a> например, в случае фиксов alsa или новых версий nvidia. > >> > >> То есть в случае других фиксов kernel-image будет пересобираться, а в > >> случае фиксов alsa нет ? То есть вынесение модуля в отдельный пакет > >> происходит исходя из частоты его обновления, я правильно понял ? > >> > >> > > a> Из асинхронности его обновления с обновлением ядра. Так > a> как в любом случае модуль пересобрать и скачать быстрее, > a> то что меняется чаще -- не суть важно. > Понятно. > > Я все-таки хочу дообсуждать тему отдельных пакетов с модулями. > Можно рассмотреть 2 схемы: > 1 - стратегия выноса в отдельные пакеты как можно большего количества > функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще > апгрэйдить на продекшен системах (без перезагрузки), можно брать и > ставить только тот функционал, который нужен. > Минусы тоже присутствуют, основной - большое количество пакетов, > ведь их нужно будет собирать под конкретные ядра. Еще один минус - придется увязывать названия пакетов с оборудованием и функционалом. Ибо для правильной установки этого в программе установки придется немного поработать. Сейчас же устанавливается ядро, в котором просто все есть. > 2 - противоположная стратегия - сборка как можно большего количества > модулей вместе с ядром, в составе kernel-image. Здесь с минусами и > плюсами все наоборот. Я бы предложил среднее: то, что необходимо для программы установки (в плане функциональности) нам нужно включать в kernel-image. Все остальное (например freeswan) - выносить в отдельные пакеты. По мере появления поставляемой из коробки функциональности (а также по мере тестирования сторонних модулей) - переносить в базовое ядро необходимые модули. > > Истина где-то между этими двумя крайностями, IMHO. > А вот где, неплохо бы выяснить. Кто что скажет ? > > И еще: Возможно было бы пойти по первой схеме, только иметь > некое базовое собранное ядро (без фич, только с фиксами) и пакеты > модулей, собранных относительно этой базы. > А окончательные kernel-image будут просто пакетами, которые будут > составлять некие наборы из базы и модулей. > Возможно в этом случае удалось бы избежать основных > недостатков схемы 1. > Давайте обсудим, считаю, что это вопрос стратегический. мне если честно не очень нравится идея сильного дробления ядра на модули. тяжело собирать, отслеживать зависимости, устанавливать и многое другое. Тогда уж лучше реализовать мою идею с поставкой не упакованного в пакет ядра и спец. скриптом, устанавливающим только необходимые для данной машины модули. Rgds, Rider --------------enig6665E802BBDC1EC307FC6298 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+nkUbqohfd2vlwKsRAsbIAJ42qqRQrmT3wfsAp1E59Rfw18cQ+QCfSl/k TTfI9Xi8+IPBP70pw651TAI= =bLDm -----END PGP SIGNATURE----- --------------enig6665E802BBDC1EC307FC6298--