Re: [d-kernel] kernel policy

["Dmitry V. Levin" <ldv@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]