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: "Dmitry V. Levin" 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> <874r4ylq0m.fsf@velvet.po.cs.msu.su> <20030416221006.GA27370@nomad.office.altlinux.org> In-Reply-To: <20030416221006.GA27370@nomad.office.altlinux.org> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: 17 Apr 2003 11:21:56 +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: Hello, Dmitry DVL> Т.е. мы будем называть пакеты с самими ядрами kernel-image-, DVL> с модулями - kernel-module-, DVL> c header'ами kernel-headers-, DVL> с исходным кодом и патчами - kernel-(fix|feat)-? DVL> Или как-то иначе? Да, я предлагаю сделать так. Тут еще один плюс - в таком подходе мы имеем только 6 категорий - фичи, фиксы, модули, сорцы, хедеры и готовые ядра. То есть катекория пакета однозначно определяется вторым элементом названия (после kernel-). А в случае kernel-alsa и т.п. такой однозначной категоризации нет. Убедил :) ? DVL> Это несколько не так, как сложилось на данный момент, но ещё один раз DVL> изменить схему ещё не поздно. Однако после этого её необходимо будет DVL> зафиксировать. Согласен. >> Очень хорошо. Но где принципы выноса какого-либо функционала в модуль ? >> Пока я вижу только принцип "потому, что так было". DVL> Речь не о том, какой функционал будет в модуле, а какой - в образе ядра. DVL> Такие вещи не подлежат фиксированию в policy. В полиси можно зафиксировать общую стратегию, применяемую в репозитарии, пусть даже она будет носить рекомендательный характер. Ведь полиси - это стратегический документ ? DVL> Модули, исходники которых живут и меняются асинхронно с самим ядром, имеет DVL> смысл собирать отдельно от ядра. Впрочем, я об этом уже говорил. Да, поддерживаю. >> Но в спорных вопросах как будем поступать ? Нужен третий, как минимум :) DVL> Третьего я вам найду, об этом не беспокойтесь. :) Ну вот и чудненько. Будем соображать на троих :) -- Best regards, Ed V. Bartosh