From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy From: Peter Novodvorsky Organization: Intoxicated by Myxomop Date: Wed, 16 Apr 2003 14:01:45 +0400 In-Reply-To: (ed@sam-solutions.net's message of "16 Apr 2003 11:44:27 +0400") Message-ID: <874r4ylq0m.fsf@velvet.po.cs.msu.su> User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux) References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit 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: Эд, привет. ed@sam-solutions.net (Ed V. Bartosh) writes: > Дык feat и fix будут говорить о том, что это патч, если уж так оно > надо. Только зачем, никак не пойму. Какая от этого польза знать что > это патч ? Давайте абстрагироваться :) Я вижу пакет > kernel-feat-security-rsback - мне обязательно знать, что это патч ? > Зачем ? Да. Конечно. :) Зачем? Чтобы отличить его от пакетов с external модулями типа kernel-alsa и kernel-drm. > По-моему сейчас строится новая схема сборки. И существующие > пакеты с бинарными модулями - это, возможно, анахронизм. С таким же > успехом можно оставить старый принцип сборки ядра, опираясь на то, что > такие ядра есть в Сизифе :) Где развитие ? > Я не предлагаю их безоговорочно убрать. Определите принципы по которым > будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне > представляется слабым доказательством. В старой системе сборки все модули собирались из одного пакета и это было очень плохо. В новой системе сборки, каждая подобная группа модулей собирается из отдельного набора пакетов. Это позволяет сборщику каждый раз не пересобирать всё при выходе новой версии группы модулей, а пользователю не тащить каждый раз огроменный пакет из сети. > PN> secfixes. будут выглядеть именно так. > Не понял, сорри. Как "так" ? kernel-fix-security- а дальше ? > Нужно определить формат, как в случае с kernel-image, например. Нет. secfixes будут выглядеть как kernel-fix-security. А ide фиксы будут выглядеть как kernel-fix-ide. > PN> Да, но то как патч распологает свои файлы, -- не дело полиси, в этом > PN> разбирается скрипт apply. > Ты сам себе протифоречишь: Я имел ввиду, то как пакет с патчами распологает свои файлы внутри его каталога, -- не дело полиси. > Если не определить, где патчи будут хранить нужные им файлы - будет > путаница. А смысл ? С внешней стороны путаницы не будет, так как всем этим будет управлять программа apply. > PN> Нет, не опциальная. Если нужно, -- можно сделать > PN> /usr/lib/kernel-build-tools/apply, а все apply программы будут просто > PN> соурсить этот файл. > Можно, конечно и так. Мне показалось более элегантным решить это с > помощью макроса. Давай я тебе его пришлю, а то так трудно > разговаривать ? Давай. > PN> В среднем, будет один и тот же алгоритм. Но надо оставить за > PN> патче-пакето-твроителями полную свободу в том, как и что патчить. > Это путь к хаосу. Здесь, IMHO, лишняя свобода только вредит. Главное, что внешний интерфейс фиксирован: программа apply. А то как она действует, -- это дело разработчика. Можно написать helper, который будут соурсить большинство apply скриптов. > Что плохого в том, что при взгляде в каталог с патчами будет виден > порядок их приложения ? Если патч сделан грамотно, он и так будет виден. Это логично. Но свободу реализации при условии сохранения интерфейса за разработчиком оставлять надо. > PN> Нужно. Почему не нужно? > Сорри, я немного неправильно выразился. KVER нужно, а APPLIED_PATCHES > и флажок ./patches/APPLIED_имя пакета дублируют друг друга. Да. > Я думаю, что флаг более универсален и прост в проверке, к тому же > можно не только для пакета в целом его выставлять, а и для конкретных > патчей тоже, если понадобится. А с переменной возни больше, > однозначно. Согласен. > >> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения. > >> устанавливаются в /usr/src/kernel/patches/название_пакета/ > > PN> Это не регулируется policy. > Дык и напрасно :) Собственно, это только мои предложения, решать > тебе. У меня есть намерение, если ты не против, включить тебя в kernel maintainer committee, когда ты станешь разработчиком, так что решать таки *нам*. > Согласен. Пусть будет рекомендательный. Это только первый шаг к > условному приложению патчей. Мне порекомендовали, например, взглянуть > на PATCH-O-MATIC, там есть на что посмотреть в этом плане. > Может быть и есть смысл попользоваться их схемой. А PATCH-O-MATIC требует своего вида apply скриптов. Я и веду к тому, что всё должно регулироваться внутри пакета. > > >> 4. При условии успешного приложения пакета патчей в каталоге ./patches > >> соответствующего дерева kernel sources должен создаваться файл > >> APPLIED_имя_пакета > > PN> Это рекоммендация. > См. выше. Предлагаю писать номер строчки или её обозначение в таких случаях. Но я и так понял. > PN> это рекоммендация. > Но, согласись, при такой схеме гораздо проще выяснить с какими файлами > работает пакет. Почему бы ее и не применять ? Потому, что если пэкэджер хороший, он сделает так, чтобы было просто выяснить. А плохих у нас нет. :) И не будет. > PN> шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым > PN> из apply-скриптов. > Я не против, в принципе. Но почему тебе так не нравится идея с > макросом ? Принципиальной разницы нет, IMHO. См. ниже [1]. > > >> 7. Нестандартная действия по установке/приложению патчей производятся > >> в скриптах имя_пакета-apply и устанавливаются в > >> /usr/src/kernel/patches/apply > > PN> Не понимаю. Зачем делать условный оператор? > Чтобы избавиться в большинстве случаев от apply скриптов. [1]. Чем так помешали apply скрипты? apply скрипт, -- это интерфейс доступа к патчу. И он фиксирован. Делать в таких случаях условный оператор не очень красиво. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite!