From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy From: Peter Novodvorsky Organization: Intoxicated by Myxomop Date: Thu, 17 Apr 2003 13:35:39 +0400 In-Reply-To: (Ed V. Bartosh's message of "17 Apr 2003 11:21:56 +0400") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3 (gnu/linux) References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> <874r4ylq0m.fsf@velvet.po.cs.msu.su> <20030416221006.GA27370@nomad.office.altlinux.org> 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: ed@altlinux.ru (Ed V. Bartosh) writes: > Hello, Dmitry > > DVL> Т.е. мы будем называть пакеты с самими ядрами kernel-image-, > DVL> с модулями - kernel-module-, > DVL> c header'ами kernel-headers-, > DVL> с исходным кодом и патчами - kernel-(fix|feat)-? > DVL> Или как-то иначе? > Да, я предлагаю сделать так. Тут еще один плюс - в таком подходе мы > имеем только 6 категорий - фичи, фиксы, модули, сорцы, хедеры и > готовые ядра. > То есть катекория пакета однозначно определяется вторым элементом > названия (после kernel-). А в случае kernel-alsa и т.п. такой однозначной > категоризации нет. Убедил :) ? Отлично-отлично. Наконец. Осталось решить последний вопрос: как будут назваться пакеты с хедерами alsa? :))) kernel-headers-alsa? [I} Кстати я вношу с солгласия Эда и Димы патчик в kernel-policy: kernel policy обновляется участниками kernel maintainer committee. Состав kernel committee: +- Ed Bartosh +- Dmitry Levin - Peter 'nidd' Novodvorsky > В полиси можно зафиксировать общую стратегию, применяемую в > репозитарии, пусть даже она будет носить рекомендательный характер. > Ведь полиси - это стратегический документ ? В качестве рекоммендации можно конечно. > DVL> Модули, исходники которых живут и меняются асинхронно с самим ядром, имеет > DVL> смысл собирать отдельно от ядра. Впрочем, я об этом уже говорил. > Да, поддерживаю. ура. > >> Но в спорных вопросах как будем поступать ? Нужен третий, как минимум :) > > DVL> Третьего я вам найду, об этом не беспокойтесь. :) > Ну вот и чудненько. Будем соображать на троих :) См патчик :) Остаются два ключевых вопроса: 1. Как прикладываются патчи (обязательность apply скрипта) 2. и [I] Кажется всё, да? Насчёт возможности собирания внешних модулей внутри ядра. В redhat используется система с директорией add-on, в которую всё кладётся. Можно, чтобы каждый source пакет (типа alsa-source) включал в себя apply скрипт, который распаковывает его самого в add-on и прописывает в Config.in себя. Хотелось бы по-быстрее завершить это обсуждение и принять базовую полиси, чтобы приступить к работе. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite! Kill 'em all, and let God sort 'em out