From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ed@altlinux.ru>
X-Mailer: Gnus v5.8.8/XEmacs 21.4 - "Portable Code"
X-Comment-To: Michael Shigorin
To: devel-kernel@altlinux.ru
Subject: Re: [d-kernel] kernel policy
References: <20030415144045.GA13440@shamrock.office.altlinux.ru>
	<m37k9vg5vk.fsf@sam-solutions.net>
	<87he8zljh6.fsf@velvet.po.cs.msu.su> <3E9C5571.2040009@altlinux.ru>
	<m3of36ev8k.fsf@sam-solutions.net> <3E9D746E.5040006@altlinux.ru>
	<m3he8ybjkl.fsf@altlinux.ru> <20030424235738.GF11315@osdn.org.ua>
In-Reply-To: <20030424235738.GF11315@osdn.org.ua>
From: ed@altlinux.ru (Ed V. Bartosh)
Organization: ALT Linux
Date: 25 Apr 2003 13:35:57 +0400
Message-ID: <m3znmehqbm.fsf@altlinux.ru>
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: <http://altlinux.ru/mailman/listinfo/devel-kernel>,
	<mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe>
List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru>
List-Post: <mailto:devel-kernel@altlinux.ru>
List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help>
List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>,
	<mailto:devel-kernel-request@altlinux.ru?subject=subscribe>
List-Archive: <http://altlinux.ru/pipermail/devel-kernel/>
Archived-At: <http://lore.altlinux.org/devel-kernel/m3znmehqbm.fsf@altlinux.ru/>
List-Archive: <http://lore.altlinux.org/devel-kernel/>
List-Post: <mailto:devel-kernel@altlinux.org>

Hello, Michael

 >> 1 - стратегия выноса в отдельные пакеты как можно большего количества
 >> функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
 >> апгрэйдить на продекшен системах (без перезагрузки), можно брать и
 >> ставить только тот функционал, который нужен. 
 >> Минусы тоже присутствуют, основной - большое количество пакетов, 
 >> ведь их нужно будет собирать под конкретные ядра.

 MS> Кстати, PLD'шную схему рассматривали?  Она, как мне кажется, уже
 MS> прошла по этому пути.

Спасибо за наводку, посмотрел. Действительно, близкая стратегия.
Наша мне больше нравится, у них ориентация на единственное ядро,
поэтому и спеки на пакеты с модулями сделаны монолитными, вместе с
сорцами и сразу на модули для up и smp ядер. У нас это гибче сделано.

Я опять таки хочу вернуться к названиям, у них ядерные пакеты
называются предельно просто: 
имидж - kernel-2.2.22-6.i586.rpm, kernel-2.2.22-6.src.rpm
модуль - kernel-net-e100-2.1.15-3@2.2.22_6.i586.rpm, 
         kernel-net-e100-2.1.15-3@2.2.22_6.src.rpm

Интересно, как у них тогда решается проблема с установкой/апгрейдом ядер,
из-за которой у нас предлагается включать версию ядра в название пакета ?

-- 
Best regards,
Ed V. Bartosh