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: Tue, 15 Apr 2003 22:10:45 +0400 In-Reply-To: (ed@sam-solutions.net's message of "15 Apr 2003 19:36:02 +0400") Message-ID: <87he8zljh6.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> 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: > n> Есть два вида патчей: > > n> kernel-patch-feat-%{upsteram_name} > n> kernel-patch-fix-%{upstream_name} > Предлагаю убрать patch- из названия: > kernel-feat-%{upsteram_name} > kernel-fix-%{upstream_name} > > По-моему достаточно информативно и короче. это не информативно. это не говорит, что это -- патч. Может ещё -source- убрать? > Предлагаю сделать пакет kernel-build-tools с макросами/скриптами/etc > применяющимися при сборке ядер. > У меня уже есть, что туда положить :) окей. > > n> 1.2 Внешние модули. > n> ------------------- > > n> Внешними модулями называются модули, исходные файлы которых > n> поставляются не в виде патчей и которые можно собрать отдельно от > n> ядра. > > n> Пакеты с такими собранными модулями должны называться > n> kernel-<сокращённое название набора модулей>-<версия ядра с которым > n> собраны модули>-. > Предлагаю kernel-module-..., соответственно kernel-module-название-headers и > kernel-module-название-source > > И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них > или хотя бы минимизировать их количество. > Или описать здесь принципы выноса бинарных модулей в отдельный пакет. > Я как-то до сих пор их не уяснил :( Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up src rpm. Нет, не судьба называть их kernel-module. > > n> 1.4 Пакет с ядром. > n> ------------------ > > n> Такой пакет должен называться kernel-image-<версия ядра>- n> ядра>. > Что есть flavor в данном случае ? > Может flavor-subflavor (std-up) ? Да-да. > > n> 2. Versioning пакетов. > n> ---------------------- > > n> Пакетам с feat патчами желательно присваивать версии, полученные из > n> upstream. Если upstream не делает versioning, допустимо называть их по > n> дате последнего изменения upstream в формате ddmmyy. > > n> Пакетам с fix патчами обязательно присваивать версии по дате > n> запаковывания в формате ddmmyy. > Здесь можно привести формат имени таких пакетов. secfixes. будут выглядеть именно так. > > n> 3.1 Патчи. > n> ---------- > > n> /usr/src/patches/<имя_патча>/* патчи > /usr/src/kernel/patches/<имя_патча>/* > > n> patches/apply/<имя_патча> программа, которая > /usr/src/kernel/patches/apply/<имя_патча> > окей-окей. > Вместе с патчами могут ставиться и тарболы, предлагаю их > ставить в /usr/src/kernel/patches/src/<имя_патча>/ > В отдельный пакет с сорцами уж точно нет смысла это выносить. Да, но то как патч распологает свои файлы, -- не дело полиси, в этом разбирается скрипт apply. > > n> прикладывает патчи > Считаю, что apply-программы вещь опциональная, а стандартное > приложение патчей должно быть выполнено в виде макроса. > Такой макрос уже есть. Нет, не опциальная. Если нужно, -- можно сделать /usr/lib/kernel-build-tools/apply, а все apply программы будут просто соурсить этот файл. > > n> Патчи внутри каталога могут находиться в любом расположении, это не > n> определяется данным документом. > Предлагаю определить, иначе будет затруднено вынесение общего > функционала в макрос. В среднем, будет один и тот же алгоритм. Но надо оставить за патче-пакето-твроителями полную свободу в том, как и что патчить. > > n> Программа прикладывающая патч, будучи вызванная из каталога с исходными > n> текстами ядра, обязана приложить к ним нужные патчи или возвратить 1 в > n> случае ошибки прикладывания. Программа может пользоваться следующими > n> переменными окружения заданными при запуске в среде: > n> - APPLIED_PATCHES, переменная содержит список названий уже приложенных > n> патчей через запятую. > n> - KVER, версия ядра, к которой нужно приложить патч. > Не уверен, что это нужно. Нужно. Почему не нужно? > > n> 3.2 Пакет с исходными текстами. > n> -------------------------------- > > n> /usr/src/<имя_пакета>-source-<версия>.tar.gz > n> .... > Это для самого ядра и для модулей ? > > Вот мои пожелания, которые я не успел отправить, вернее их часть. > Примите во внимание, плз: > > Принципы сборки/установки: > 1. Тарболы с сорцами ядер устанавливаются в /usr/src > 2. Пачти называются NN-название.patch, где NN определяет порядок приложения. > устанавливаются в /usr/src/kernel/patches/название_пакета/ Это не регулируется policy. > 3. Условное приложение патчей достигается путем установки > патча в каталог /usr/src/kernel/patches/название_пакета/название_required_пакета > Такой патч будет приложен только при условии того, что приложены > патчи из пакета 'название_required_пакета' Это рекоммендованный но не обязательный способ. > 4. При условии успешного приложения пакета патчей в каталоге ./patches > соответствующего дерева kernel sources должен создаваться файл > APPLIED_имя_пакета Это рекоммендация. > 5. Тарболы с сорцами, используемыми пакетом с патчами устанавливаются в > /usr/src/kernel/patches/src/название_пакета/ это рекоммендация. > 6. Стандартные действия по установке патчей производятся с помощью > макроса(ов) из пакета kernel-build-tools шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым из apply-скриптов. > 7. Нестандартная действия по установке/приложению патчей производятся > в скриптах имя_пакета-apply и устанавливаются в > /usr/src/kernel/patches/apply Не понимаю. Зачем делать условный оператор? > 8. Распаковка sources, приложение патчей производится > при сборке kernel-image Да. > 9. В репозитарии не должно быть бинарных пакетов с модулями, все > модули должны находиться в соответствующем kernel-image Нет. Все модули, которые могут собираться отдельно от ядра собираются отдельно от ядра. как то: alsa, i2c, lm_sensors, и так далее, см. сизиф. Спасибо за комментарии, Пётр. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite!