From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Mailer: Gnus v5.8.8/XEmacs 21.4 - "Portable Code" X-Comment-To: Peter Novodvorsky To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> <874r4ylq0m.fsf@velvet.po.cs.msu.su> In-Reply-To: <874r4ylq0m.fsf@velvet.po.cs.msu.su> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: 16 Apr 2003 14:15:16 +0400 Message-ID: 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: 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