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> In-Reply-To: <87he8zljh6.fsf@velvet.po.cs.msu.su> From: ed@sam-solutions.net (Ed V. Bartosh) Organization: SaM-Solutions Ltd. Date: 16 Apr 2003 11:44:27 +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 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