Kernel Policy for Sisyphus. =========================== Version: 1.2 0. Документ и его обновление. ----------------------------- kernel policy обновляется участниками kernel maintainer committee. Состав kernel committee: - Ed V. Bartosh - Dmitry V. Levin - Peter A. Novodvorsky - Sergey Vlasov 1. Именование ------------- 1.1 Патчи. ---------- Есть два вида патчей: kernel-feat-%{upstream_name} kernel-fix-%{upstream_name} Название пакетов с патчами базируется на иерархии каталогов в исходных текстах ядра, в соответствии с местом основного приложения патча. В пакетах feat содержатся патчи, добавляющие ядру Linux новые возможности. Это могут быть и драйверы устройств (рекомендуется называть такие kernel-feat-drivers-<имя_устройства>), и файловых систем (желательно называть kernel-feat-fs-<имя_файловой системы>), добавление новых возможностей к сетевой подсистеме (желательно называть kernel-feat-net-<сокращённое название улучшения>), а также добавление новых возможностей к корневой части (kernel/*, mm/*, arch/*) ядра, (желательно называть kernel-feat-core-<название улучшения>). При именовании патчей рекомендуется следовать иерархии каталогов в исходных текстах ядра. Все пакеты fix поддерживаются kernel maintainer commitee. Именуются по именам подсистем ядра, а также существует отдельный пакет для security патчей и build патчей: kernel-fix-{net,drivers,fs,vm,core,security,build}. Глубина иерархии в названии пакета может варьироваться, некоторые уровни - пропускаться, чтобы сделать название короче, например, kernel-net-netfilter вместо kernel-net-ipv4-netfilter и kernel-net-ipv6-netfilter. 1.2 Внешние модули. ------------------- Внешними модулями называются модули, исходные файлы которых, как правило, поставляются не в виде патчей, и которые собираются отдельно от ядра. Пакеты с такими собранными модулями должны называться kernel-modules-<сокращённое название набора модулей>-. Пакеты с заголовочными файлами этих модулей должны называться kernel-headers-<сокращённое название набора модулей>-. Такие пакеты могут и не существовать, они требуются лишь в том случае, когда эти заголовочные файлы требуются для утилит или других модулей. Если по каким-то причинам необходимо собирать несколько различных версий одного пакета с модулями (например, в случае, когда в новой версии есть проблемы с поддержкой старых устройств), для таких пакетов в имя пакета должна быть добавлена версия: kernel-modules-<имя_проекта>-<версия_модулей>-. 1.3 Пакеты с исходными текстами модулей. ---------------------------------------- Такие пакеты должны называться: kernel-source-<имя проекта>, либо kernel-source-<имя проекта>-<версия модулей>, если требуется одновременная установка нескольких версий такого пакета. 1.4 Пакеты с исходными текстами ядра. ------------------------------------- Такие пакеты должны называться: kernel-source-<версия ядра без суффикса (rc*|pre*)>. Версия такого пакета формируется по следующему правилу: # 0.0.X -- preX # 0.X.0 -- rcX # 1.0.0 -- release 1.5 Пакеты с ядром. ------------------ Такие пакеты должны называться kernel-image-. Пакеты с заголовочными файлами ядра должны называться kernel-headers-. Пакеты с внутренними заголовочными файлами ядра, которые необходимы только для сборки модулей для этого ядра (например, внутренние заголовки подсистемы SCSI), должны называться kernel-headers-modules-. 1.6 Пакеты kernel-complete -------------------------- Такие пакеты должны называться kernel-complete-. Пакет kernel-complete- должен содержать зависимости на соответствующий пакет с ядром (kernel-image-) и на все собранные для этого ядра пакеты с внешними модулями (kernel-modules-<набор_модулей>-), за исключением пакетов со старыми версиями модулей, которые конфликтуют с более новыми версиями аналогичных модулей. 1.7 Пакет rpm-build-kernel -------------------------- В этом пакете содержатся rpm определения, макросы, скрипты и другие вспомогательные средства, которые рекомендуется использовать в spec файлах kernel- пакетов и в apply скриптах. В том числе в файле /etc/rpm/macros.d/kernel содержится макрос, который используется при прикладывании патчей, если отсутствует приложенный apply скрипт. 1.8 Пакет kernel-build-tools ---------------------------- В этом пакете содержатся скрипты, используемые мантейнерами пакетов ядра и дополнительных модулей при подготовке пакетов. Этот пакет не должен присутствовать в BuildRequires у создаваемых пакетов - если какие-то скрипты действительно необходимы на этапе сборки, такие скрипты должны быть помещены в пакет rpm-build-kernel. 2. Versioning пакетов. ---------------------- Пакетам с feat патчами желательно присваивать версии, полученные из upstream. Если upstream не делает versioning, допустимо называть их по дате последнего изменения upstream в формате yyyy.mm.dd. Пакетам с fix патчами обязательно присваивать версии по дате запаковывания в формате yyyy.mm.dd. Пакетам с внешними модулями и ядром, а также с исходными текстами модулей, желательно присваивать версии, полученные из upstream. Если upstream не делает versioning, допустимо называть их по дате последнего изменения upstream в формате yyyy.mm.dd. Пакетам с исходными текстами ядра присваиваются версии по следующей схеме: - если это версия preX, то версия пакета будет 0.0.X. - если это версия rcX, то версия пакета будет 0.X.0. - если это релиз, то версия пакета будет 1.0.0. 3. Содержимое пакетов. ---------------------- 3.1 Патчи. ---------- /usr/src/kernel/patches/<имя_пакета>/* патчи optional: kernel/patches/apply/<имя_пакета> программа, которая прикладывает патчи Пакеты с патчами могут быть двух типов: 1) Содержащие только патчи в формате unified diff (или context diff) для применения с помощью patch -p1, и не содержащие своей программы для приложения патчей. В этом случае для применения патчей используется встроенный алгоритм из rpm-build-kernel (см. раздел 5). 2) Содержащие собственную программу (apply-скрипт) для приложения патчей. В этом случае формат файлов, помещаемых в каталог /usr/src/kernel/patches/<имя_пакета>/, может быть любым. 3.1.1 Патчи без собственной программы для приложения ---------------------------------------------------- В простейшем случае пакет патчей может состоять из набора patch-файлов в каталоге /usr/src/kernel/patches/<имя_пакета>. Файлы с патчами рекомендуется называть по шаблону "NN_name.patch", где NN -- номер патча, определяющий порядок его приложения. Если часть патчей в пакете нужно прикладывать не всегда, можно использовать следующие средства: - Чтобы патч NN_name.patch не прикладывался к версии ядра X.Y.ZZ, нужно создать в том же каталоге пустой файл с именем dont_apply_to_X.Y.ZZ_NN_name.patch. - Для применения группы патчей только к определённой версии ядра (X.Y.ZZ) эти патчи следует поместить в подкаталог NN_apply_to_X.Y.ZZ. - Для применения группы патчей только к определённой ветке ядер (X.Y) эти патчи следует поместить в подкаталог NN_X.Y. - Если группу патчей необходимо прикладывать только в том случае, если ранее был применён другой пакет патчей (kernel-AAA-BBB), эти патчи следует поместить в подкаталог NN_kernel-AAA-BBB. Если при обработке такого подкаталога обнаруживается, что указанный пакет патчей входит в список патчей для собираемого ядра, но ещё не был приложен, он прикладывается перед обработкой патчей из подкаталога. - Если группу патчей необходимо прикладывать только в том случае, если другой пакет патчей (kernel-AAA-BBB) не прикладывается к собираемому ядру, эти патчи следует поместить в подкаталог NN_not_kernel-AAA-BBB. - Патчи, помещённые в подкаталог NN_common, применяются в любом случае (эта возможность может использоваться для группировки патчей в нужном порядке). 3.1.2 Патчи с собственной программой для приложения --------------------------------------------------- Если для применения патчей недостаточно возможностей стандартного алгоритма, необходимые для этого действия должны выполняться скриптом для /bin/sh, расположенным в каталоге /usr/src/kernel/patches/apply/; имя файла должно совпадать с именем пакета патчей. Apply-скрипт вызывается из каталога с исходными текстами ядра; ему передаются следующие параметры: - $1 - имя каталога для патчей (/usr/src/kernel/patches); - $2 - имя пакета патчей; - $3 - версия ядра; - $4 - ветка ядра. Если в процессе наложения патчей произошла ошибка, apply-скрипт должен возвратить ненулевой код завершения. При прикладывании патчей apply-скрипт может руководствоваться файлами в подкаталоге исходных текстов ядра patches/ формата APPLIED_$name. Существование таких файлов означает, что приложены патчи с именами $name. Скрипт не должен создавать файл APPLIED_$name со своим именем в этом каталоге - этот файл создаётся стандартными функциями из rpm-build-kernel после успешного завершения apply-скрипта. 3.1.3 Макросы для spec-файлов пакетов с патчами ----------------------------------------------- Поскольку пакет с патчами может включать большое число исходных файлов, над которыми выполняются однотипные действия, в пакете rpm-build-kernel определены макросы %source и %install_patches, позволяющие существенно сократить размер spec-файла таких пакетов. Макрос %source следует использовать для перечисления файлов патчей вместо встроенной конструкции SourceN: file в заголовке spec-файла: %source <номер> <имя_файла> [<подкаталог>] Помимо добавления указанного файла в список исходных файлов пакета (Source<номер>: <имя_файла>), при этом указанное имя файла сохраняется в списке файлов для последующей установки. Кроме того, может быть указан необязательный подкаталог для установки этого файла. Далее в секции %install может использоваться макрос для установки файлов, перечисленных в %source: %install_patches При выполнении этого макроса файлы, перечисленные в %source, устанавливаются в каталог %patches_dir/%patch_name (макрос %patch_name должен быть определён в spec-файле перед использованием %install_patches). Если для файла в %sources был указан подкаталог, этот файл будет установлен в соответствующий подкаталог каталога %patches_dir/%patch_name. 3.2 Пакет с исходными текстами. -------------------------------- /usr/src/kernel/sources/<имя_пакета>-<версия>.tar.gz или /usr/src/kernel/sources/<имя_пакета>-<версия>.tar.bz2 3.3 Пакет с внешними модулями. ------------------------------- /lib/modules/<версия ядра>-/* /usr/include/linux-<версия ядра>-/include/* 3.4 Пакет с ядром. ------------------ image: /boot/config-<версия ядра>-- /boot/vmlinuz-<версия ядра>-- /boot/System.map-<версия ядра>-- /lib/modules/<версия ядра>--/* headers: /usr/include/linux-<версия ядра>-/* headers-modules: /usr/src/linux-<версия ядра>-/* 4. Зависимости пакетов и установочные скрипты --------------------------------------------- 4.1 Пакеты с ядром ------------------ В пакетах kernel-image-* должны быть указаны следующие зависимости: BuildRequires(pre): rpm-build-kernel Provides: kernel = %kversion Provides: kernel24 = %kversion (только для ядер 2.4.x) Obsoletes: kernel-modules Obsoletes: kernel-modules-i2c-%flavour PreReq: bootloader-utils >= 0.3-alt1 Установочные скрипты пакетов kernel-image-* должны содержать: %post %post_kernel_image %kversion-%flavour-%krelease %preun %preun_kernel_image %kversion-%flavour-%krelease 4.2 Пакеты с заголовками ядра ----------------------------- Пакеты kernel-headers- должны иметь следующие зависимости: BuildRequires(pre): rpm-build-kernel Requires: kernel-headers-common >= 1.1 Obsoletes: kernel-headers-i2c-%flavour Provides: kernel-headers Provides: kernel-headers-%base_flavour Provides: kernel24-headers (только для ядер 2.4.x) Здесь %base_flavour - первая часть %flavour (без указания "-up" или "-smp"). Пакеты kernel-headers-modules- должны иметь зависимость на соответствующий пакет kernel-headers- с точным указанием версии и сборки: Requires: kernel-headers-%flavour = %version-%release Установочные скрипты пакетов kernel-headers- должны содержать: %post -n kernel-headers-%flavour %post_kernel_headers %kversion-%flavour-%krelease %postun -n kernel-headers-%flavour %postun_kernel_headers %kversion-%flavour-%krelease 4.3 Пакеты с внешними модулями ------------------------------ Пакеты с модулями (kernel-modules-<набор_модулей>-) должны иметь зависимость PreReq на пакет ядра (kernel-image-), для которого они собраны, с точным указанием версии и сборки. При наличии зависимостей между модулями, содержащимися в разных пакетах, должны присутствовать соответствующие зависимости (PreReq) между этими пакетами, также с точным указанием версии и сборки. Кроме того, пакеты с модулями должны иметь зависимости вида: Provides: kernel-modules-%module_name-%kversion-%flavour-%krelease = %version-%release Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease < %version-%release Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease > %version-%release Эти зависимости обеспечивают наличие в системе не более одного пакета с одинаковыми модулями для каждого ядра (в противном случае попытка установки нескольких таких пакетов приведёт к конфликтам по файлам). В случае, когда по каким-либо причинам необходимо собирать несколько версий одного и того же модуля для одного ядра, необходимо либо обеспечить отсутствие совпадающих имён модулей в этих пакетах (путём переименования модулей), либо сделать одновременную установку таких пакетов с модулями невозможной (для этого в вышеприведённых зависимостях %module_name должно быть одинаковым, несмотря на различающиеся имена пакетов). Необходимые зависимости сборки (для макросов, используемых в установочных скриптах): BuildRequires(pre): rpm-build-kernel Установочные скрипты пакетов kernel-modules-* должны содержать: %post %post_kernel_modules %kversion-%flavour-%krelease %postun %postun_kernel_modules %kversion-%flavour-%krelease 4.4 Прочие пакеты ----------------- Никакие пакеты, кроме kernel-modules-* и kernel-complete-*, не должны иметь зависимостей на пакеты kernel-image-* и kernel-modules-* (как прямых, так и косвенных через Provides в пакетах kernel-image-* и kernel-modules-*). В будущем это требование может быть ослаблено после внесения в apt необходимой функциональности для правильной обработки зависимостей на пакеты ядра. 5. Порядок приложения патчей при сборке по умолчанию. ----------------------------------------------------- При построении исходных текстов для сборки spec ядра вызывает макрос %apply_patches для приложения патчей, который содержится в пакете rpm-build-kernel. Макрос %apply_patches вызывается следующим образом: %apply_patches <ветка> В параметре <ветка> должна быть указана часть версии ядра major.minor (например, 2.4 или 2.6). Для каждого пакета патчей, указанного в списке, макрос %apply_patches проверяет наличие apply-скрипта, и при его наличии вызывает его для применения патча. При отсутствии apply-скрипта используется встроенный алгоритм применения патчей. Содержимое каталога /usr/src/kernel/patches/<имя_пакета_патчей>/ обрабатывается в алфавитном порядке (предполагается, что при сборке выставлено LC_COLLATE=C). Каждый элемент (файл или каталог) обрабатывается следующим образом: 1) Если в том же каталоге существует (пустой) файл с именем dont_apply_to_<версия_ядра>_<имя_файла>, элемент (файл или каталог) пропускается. 2) Подкаталоги обрабатываются в зависимости от их имени (имя задаёт условия применения содержащихся в подкаталоге патчей). Начальная часть имени, соответствующая маске ??_, игнорируется (это позволяет устанавливать порядок обработки подкаталогов путём добавления префиксов вида 10_). Оставшаяся часть имени обрабатывается следующим образом: - common - патчи применяются в любом случае. - <ветка> - патчи применяются только к ядрам этой ветки. - apply_to_<версия_ядра> - патчи применяются только к указанной версии ядра. - <имя_пакета_патчей> - патчи применяются только в том случае, если в списке пакетов патчей для собираемого ядра есть указанный пакет. Кроме того, если в этот момент указанный пакет патчей ещё не был применён (поскольку находится в списке патчей после текущего), он применяется немедленно (это важно в случае, когда патчи модифицируют одни и те же файлы). - not_<имя_пакета_патчей> - патчи применяются только в том случае, если в списке пакетов патчей для собираемого ядра нет указанного пакета. При выполнении условия алгоритм применяется рекурсивно к содержимому подкаталога. 3) Обычные файлы используются в качестве входных файлов для программы patch; вызов patch производится с опцией -p1. После успешного применения пакета патчей создаётся файл patches/APPLIED_<имя_пакета_патчей>; наличие этого файла может быть использовано в apply-скриптах для проверки, был ли применён ранее тот или иной пакет патчей. 6. Переключение заголовочных файлов. ------------------------------------ После загрузки ссылки, на которые указывают /usr/include/{linux,asm}, направляются на заголовочные файлы, соответствующие текущему ядру. Если последние отсутствуют, то ссылки перенаправляются на заголовочные файлы из пакета glibc-kernheaders, лежащие в каталоге /usr/include/linux-default. 7. Порядок принятия новых пакетов в Sisyphus. --------------------------------------------- Дабы упорядочить вхождение новых пакетов в Sisyphus, сначала разработчик обязан написать письмо в devel-kernel@altlinux.ru с темой ITP: <имя_пакета> (Intent to package) и с description-ом пакета в теле, чтобы пояснить, что новое он хочет добавить. Далее проходит обсуждение этого пакета, и люди договариваются, целесообразно ли присутствие пакета в Sisyphus. Kernel maintainer committee имеет право наложить вето на вхождение пакета в Sisyphus при согласии всех участников KMC.