[d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Peter

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

 PN> это не информативно. это не говорит, что это -- патч. Может ещё
 PN> -source- убрать?
Дык feat и fix будут говорить о том, что это патч, если уж так оно
надо. Только зачем, никак не пойму. Какая от этого польза знать что
это патч ? Давайте абстрагироваться :) Я вижу пакет
kernel-feat-security-rsback - мне обязательно знать, что это патч ?
Зачем ?


 >> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
 >> или хотя бы минимизировать их количество. 
 >> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
 >> Я как-то до сих пор их не уяснил :(

 PN> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
 PN> src rpm. Нет, не судьба называть их kernel-module.
По-моему сейчас строится новая схема сборки. И существующие
пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
успехом можно оставить старый принцип сборки ядра, опираясь на то, что
такие ядра есть в Сизифе :) Где развитие ?
Я не предлагаю их безоговорочно убрать. Определите принципы по которым
будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
представляется слабым доказательством.

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

 PN> secfixes. будут выглядеть именно так.
Не понял, сорри. Как "так" ? kernel-fix-security- а дальше ?
Нужно определить формат, как в случае с kernel-image, например.

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

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

/usr/src/patches/<имя_патча>/*            патчи
         patches/apply/<имя_патча>        программа, которая
                                          прикладывает патчи

Если не определить, где патчи будут хранить нужные им файлы - будет
путаница. А смысл ?

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

 PN> Нет, не опциальная. Если нужно, -- можно сделать
 PN> /usr/lib/kernel-build-tools/apply, а все apply программы будут просто
 PN> соурсить этот файл.
Можно, конечно и так. Мне показалось более элегантным решить это с
помощью макроса. Давай я тебе его пришлю, а то так трудно
разговаривать ?
С помощью этого макроса я сейчас легко обхожусь без apply скриптов
в большинстве пакетов (xfs, secfixes, evms прикладываются без проблем).

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

 PN> В среднем, будет один и тот же алгоритм. Но надо оставить за
 PN> патче-пакето-твроителями полную свободу в том, как и что патчить. 
Это путь к хаосу. Здесь, IMHO, лишняя свобода только вредит.
Что плохого в том, что при взгляде в каталог с патчами будет виден
порядок их приложения ?

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

 PN> Нужно. Почему не нужно?
Сорри, я немного неправильно выразился. KVER нужно, а APPLIED_PATCHES
и флажок ./patches/APPLIED_имя пакета дублируют друг друга.
Я думаю, что флаг более универсален и прост в проверке, к тому же
можно не только для пакета в целом его выставлять, а и для конкретных
патчей тоже, если понадобится. А с переменной возни больше, однозначно.

 >> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
 >> устанавливаются в /usr/src/kernel/patches/название_пакета/

 PN> Это не регулируется policy.
Дык и напрасно :) Собственно, это только мои предложения, решать тебе.

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

 PN> Это рекоммендованный но не обязательный способ.
Согласен. Пусть будет рекомендательный. Это только первый шаг к 
условному приложению патчей. Мне порекомендовали, например, взглянуть
на PATCH-O-MATIC, там есть на что посмотреть в этом плане.
Может быть и есть смысл попользоваться их схемой.

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

 PN> Это рекоммендация.
См. выше.

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

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

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

 PN> шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым
 PN> из apply-скриптов.
Я не против, в принципе. Но почему тебе так не нравится идея с
макросом ? Принципиальной разницы нет, IMHO.

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

 PN> Не понимаю. Зачем делать условный оператор?
Чтобы избавиться в большинстве случаев от apply скриптов.

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

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

-- 
Best regards,
Ed V. Bartosh