From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 17 Apr 2003 02:10:06 +0400 From: "Dmitry V. Levin" To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy Message-ID: <20030416221006.GA27370@nomad.office.altlinux.org> Mail-Followup-To: devel-kernel@altlinux.ru References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> <874r4ylq0m.fsf@velvet.po.cs.msu.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 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: --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Apr 16, 2003 at 02:15:16PM +0400, Ed V. Bartosh wrote: > >> Дык feat и fix будут говорить о том, что это патч, если уж так оно > >> надо. Только зачем, никак не пойму. Какая от этого польза знать что > >> это патч ? Давайте абстрагироваться :) Я вижу пакет > >> kernel-feat-security-rsback - мне обязательно знать, что это патч ? > >> Зачем ? > > PN> Да. Конечно. :) Зачем? Чтобы отличить его от пакетов с external > PN> модулями типа kernel-alsa и kernel-drm. > Их я предлагал называть kernel-module-alsa и т.п. > По-моему термин module более понятен "конечному пользователю", чем > patch. Зачем людей пугать :) Т.е. мы будем называть пакеты с самими ядрами kernel-image-, с модулями - kernel-module-, c header'ами kernel-headers-, с исходным кодом и патчами - kernel-(fix|feat)-? Или как-то иначе? Это несколько не так, как сложилось на данный момент, но ещё один раз изменить схему ещё не поздно. Однако после этого её необходимо будет зафиксировать. > PN> В старой системе сборки все модули собирались из одного пакета и это > PN> было очень плохо. В новой системе сборки, каждая подобная группа > PN> модулей собирается из отдельного набора пакетов. Это позволяет > PN> сборщику каждый раз не пересобирать всё при выходе новой версии группы > PN> модулей, а пользователю не тащить каждый раз огроменный пакет из > PN> сети. > Очень хорошо. Но где принципы выноса какого-либо функционала в модуль ? > Пока я вижу только принцип "потому, что так было". Речь не о том, какой функционал будет в модуле, а какой - в образе ядра. Такие вещи не подлежат фиксированию в policy. Модули, исходники которых живут и меняются асинхронно с самим ядром, имеет смысл собирать отдельно от ядра. Впрочем, я об этом уже говорил. > PN> У меня есть намерение, если ты не против, включить тебя в kernel > PN> maintainer committee, когда ты станешь разработчиком, так что решать > PN> таки *нам*. > Я не против, включай, разработчиком я уже стал. > Но в спорных вопросах как будем поступать ? Нужен третий, как минимум :) Третьего я вам найду, об этом не беспокойтесь. :) -- ldv --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ndS99viEa8HiNCkRAioHAJsGV09syT+4NcWD2SuG1ChwA4yt5wCfZVd2 IY1fLb/DmtBSbu+Ox9VI0Vo= =cFeu -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY--