Re: [d-kernel] kernel policy

[ed@altlinux.ru (Ed V. Bartosh)]

Hello, Peter

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

 PN> Да. Конечно. :) Зачем? Чтобы отличить его от пакетов с external
 PN> модулями типа kernel-alsa и kernel-drm.
Их я предлагал называть kernel-module-alsa и т.п. 
По-моему термин module более понятен "конечному пользователю", чем
patch. Зачем людей пугать :)

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

 PN> В старой системе сборки все модули собирались из одного пакета и это
 PN> было очень плохо. В новой системе сборки, каждая подобная группа
 PN> модулей собирается из отдельного набора пакетов. Это позволяет
 PN> сборщику каждый раз не пересобирать всё при выходе новой версии группы
 PN> модулей, а пользователю не тащить каждый раз огроменный пакет из
 PN> сети. 
Очень хорошо. Но где принципы выноса какого-либо функционала в модуль ? 
Пока я вижу только принцип "потому, что так было".

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

 PN> Нет. secfixes будут выглядеть как kernel-fix-security. А ide фиксы
 PN> будут выглядеть как kernel-fix-ide.
А где будут даты, чето я нить теряю :( 
Я писал насчет отражения в полиси точного формата имен пакетов,
содержащих дату в своем имени.

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

 PN> Я имел ввиду, то как пакет с патчами распологает свои файлы внутри его
 PN> каталога, -- не дело полиси.
Почему ? Это, IMHO, привнесет некий порядок, который никому не
помешает, а выгода налицо - все лежит в предсказуемых местах.
А то завтра я тебе пришлю пакет, в котором тарбол поставлю в
/var/db/tarbals и буду с пеной у рта доказывать, что это не
противоречит полиси :)

 PN> Главное, что внешний интерфейс фиксирован: программа apply. А то как
 PN> она действует, -- это дело разработчика. Можно написать helper,
 PN> который будут соурсить большинство apply скриптов.

 >> Что плохого в том, что при взгляде в каталог с патчами будет виден
 >> порядок их приложения ?

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


 >> >> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
 >> >> устанавливаются в /usr/src/kernel/patches/название_пакета/
 >> 
 PN> Это не регулируется policy.
 >> Дык и напрасно :) Собственно, это только мои предложения, решать
 >> тебе.

 PN> У меня есть намерение, если ты не против, включить тебя в kernel
 PN> maintainer committee, когда ты станешь разработчиком, так что решать
 PN> таки *нам*.
Я не против, включай, разработчиком я уже стал.
Но в спорных вопросах как будем поступать ? Нужен третий, как минимум :)

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

 PN> А PATCH-O-MATIC требует своего вида apply скриптов. Я и веду к тому,
 PN> что всё должно регулироваться внутри пакета.
А я к тому, что должна быть и общая политика, отраженная в полиси,
пусть даже рекомендательного характера.

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

 PN> Потому, что если пэкэджер хороший, он сделает так, чтобы было просто
 PN> выяснить. А плохих у нас нет. :) И не будет.
Это эмоции чистой воды. Чтобы их не было и делается полиси.

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

 PN> [1]. Чем так помешали apply скрипты? apply скрипт, -- это интерфейс
 PN> доступа к патчу. И он фиксирован. Делать в таких случаях условный
 PN> оператор не очень красиво.
Они не помешали. Но, возможно, в большинстве случаев они будут не
нужны. Зачем упражняться в Cut&Paste, когда можно эту энергию
направить на более полезные цели :) ? Например доведения 
макроса %apply_patches до универсального состояния :)

-- 
Best regards,
Ed V. Bartosh