[d-kernel] kernel policy

[Peter Novodvorsky]

ed на sam-solutions.net (Ed V. Bartosh) writes:

>  n> Есть два вида патчей:
>
>  n> kernel-patch-feat-%{upsteram_name}
>  n> kernel-patch-fix-%{upstream_name}
> Предлагаю убрать patch- из названия:
> kernel-feat-%{upsteram_name}
> kernel-fix-%{upstream_name}
>
> По-моему достаточно информативно и короче.

это не информативно. это не говорит, что это -- патч. Может ещё
-source- убрать?

> Предлагаю сделать пакет kernel-build-tools с макросами/скриптами/etc
> применяющимися при сборке ядер.
> У меня уже есть, что туда положить :)

окей.

>
>  n> 1.2 Внешние модули.
>  n> -------------------
>
>  n> Внешними модулями называются модули, исходные файлы которых
>  n> поставляются не в виде патчей и которые можно собрать отдельно от
>  n> ядра.
>
>  n> Пакеты с такими собранными модулями должны называться
>  n> kernel-<сокращённое название набора модулей>-<версия ядра с которым
>  n> собраны модули>-<flavour ядра с которым собраны модули>.
> Предлагаю kernel-module-..., соответственно kernel-module-название-headers и
> kernel-module-название-source
>
> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
> или хотя бы минимизировать их количество. 
> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
> Я как-то до сих пор их не уяснил :(

Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
src rpm. Нет, не судьба называть их kernel-module.

>
>  n> 1.4 Пакет с ядром.
>  n> ------------------
>
>  n> Такой пакет должен называться kernel-image-<версия ядра>-<flavour
>  n> ядра>.
> Что есть flavor в данном случае ?
> Может flavor-subflavor (std-up) ?

Да-да.


>
>  n> 2. Versioning пакетов.
>  n> ----------------------
>
>  n> Пакетам с feat патчами желательно присваивать версии, полученные из
>  n> upstream. Если upstream не делает versioning, допустимо называть их по
>  n> дате последнего изменения upstream в формате ddmmyy.
>
>  n> Пакетам с fix патчами обязательно присваивать версии по дате
>  n> запаковывания в формате ddmmyy.
> Здесь можно привести формат имени таких пакетов.


secfixes. будут выглядеть именно так.

>
>  n> 3.1 Патчи.
>  n> ----------
>
>  n> /usr/src/patches/<имя_патча>/*            патчи
> /usr/src/kernel/patches/<имя_патча>/*
>
>  n> patches/apply/<имя_патча>        программа, которая
> /usr/src/kernel/patches/apply/<имя_патча>
>


окей-окей.

> Вместе с патчами могут ставиться и тарболы, предлагаю их
> ставить в /usr/src/kernel/patches/src/<имя_патча>/
> В отдельный пакет с сорцами уж точно нет смысла это выносить.

Да, но то как патч распологает свои файлы, -- не дело полиси, в этом
разбирается скрипт apply.

>
>  n> прикладывает патчи
> Считаю, что apply-программы вещь опциональная, а стандартное
> приложение патчей должно быть выполнено в виде макроса.
> Такой макрос уже есть.

Нет, не опциальная. Если нужно, -- можно сделать
/usr/lib/kernel-build-tools/apply, а все apply программы будут просто
соурсить этот файл.

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


В среднем, будет один и тот же алгоритм. Но надо оставить за
патче-пакето-твроителями полную свободу в том, как и что патчить. 

>
>  n> Программа прикладывающая патч, будучи вызванная из каталога с исходными
>  n> текстами ядра, обязана приложить к ним нужные патчи или возвратить 1 в
>  n> случае ошибки прикладывания. Программа может пользоваться следующими
>  n> переменными окружения заданными при запуске в среде:
>  n> - APPLIED_PATCHES, переменная содержит список названий уже приложенных
>  n> патчей через запятую.
>  n> - KVER, версия ядра, к которой нужно приложить патч.
> Не уверен, что это нужно. 

Нужно. Почему не нужно?


>
>  n> 3.2 Пакет с исходными текстами.
>  n> --------------------------------
>
>  n> /usr/src/<имя_пакета>-source-<версия>.tar.gz
>  n> ....
> Это для самого ядра и для модулей ?
>
> Вот мои пожелания, которые я не успел отправить, вернее их часть.
> Примите во внимание, плз:
>
> Принципы сборки/установки:
> 1. Тарболы с сорцами ядер устанавливаются в /usr/src
> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
>    устанавливаются в /usr/src/kernel/patches/название_пакета/

Это не регулируется policy.

> 3. Условное приложение патчей достигается путем установки
>    патча в каталог /usr/src/kernel/patches/название_пакета/название_required_пакета
>    Такой патч будет приложен только при условии того, что приложены
>    патчи из пакета 'название_required_пакета'

Это рекоммендованный но не обязательный способ.

> 4. При условии успешного приложения пакета патчей в каталоге ./patches
>    соответствующего дерева kernel sources должен создаваться файл
>    APPLIED_имя_пакета

Это рекоммендация.

> 5. Тарболы с сорцами, используемыми пакетом с патчами устанавливаются в 
>    /usr/src/kernel/patches/src/название_пакета/

это рекоммендация.

> 6. Стандартные действия по установке патчей производятся с помощью
>    макроса(ов) из пакета kernel-build-tools 

шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым
из apply-скриптов.

> 7. Нестандартная действия по установке/приложению патчей производятся
>    в скриптах имя_пакета-apply и устанавливаются в
> /usr/src/kernel/patches/apply

Не понимаю. Зачем делать условный оператор?

> 8. Распаковка sources, приложение патчей производится
>    при сборке kernel-image

Да.

> 9. В репозитарии не должно быть бинарных пакетов с модулями, все
>    модули должны находиться в соответствующем kernel-image

Нет. Все модули, которые могут собираться отдельно от ядра собираются
отдельно от ядра. как то: alsa, i2c, lm_sensors, и так далее,
см. сизиф.

Спасибо за комментарии,
Пётр.

-- 
Peter Novodvorsky                             nidd на myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!