[devel] [RFC] kernel-policy 1.2
Sergey Vlasov
=?iso-8859-1?q?vsu_=CE=C1_altlinux=2Eru?=
Пн Янв 26 17:41:39 MSK 2004
Hello!
На обсуждение выносится исправленная и дополненная редакция
kernel-policy. Изменений достаточно много:
- Добавлено описание средств для условного применения патчей (часть
этих возможностей уже была в kernel-build-tools, но без
документации; часть была добавлена в процессе работы над ядрами
2.6.x).
- Добавлено описание макросов для пакетов с патчами (%source и
%install_patches).
- Добавлены требования к зависимостям пакетов. Возможно, часть
зависимостей для совместимости в действительности лишняя (у меня
есть сомнения по поводу Obsoletes: kernel-modules-i2c-%flavour -
подозреваю, что при этом происходит не то, что имели в виду).
Пример spec-файла ядра пока удалён - он устарел, а текущие
spec-файлы перед включением в policy в качестве примера нуждаются в
чистке. :)
Прошу заинтересованных высказаться по этому поводу.
--
Sergey Vlasov
----------- следующая часть -----------
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-<сокращённое название набора модулей>-<flavour ядра с
которым собраны модули>.
Пакеты с заголовочными файлами этих модулей должны называться
kernel-headers-<сокращённое название набора модулей>-<flavour ядра с
которым собраны модули>. Такие пакеты могут и не существовать, они
требуются лишь в том случае, когда эти заголовочные файлы требуются
для утилит или других модулей.
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-<flavour ядра>.
Пакеты с заголовочными файлами ядра должны называться
kernel-headers-<flavour ядра>.
Пакеты с внутренними заголовочными файлами ядра, которые необходимы
только для сборки модулей для этого ядра (например, внутренние
заголовки подсистемы SCSI), должны называться
kernel-headers-modules-<flavour ядра>.
1.6 Пакет kernel-build-tools
----------------------------
В этом пакете содержатся rpm определения, макросы, скрипты и другие
вспомогательные средства, которые рекомендуется использовать в spec
файлах kernel- пакетов и в apply скриптах. В том числе в файле
/etc/rpm/macros.d/kernel содержится макрос, который используется при
прикладывании патчей, если отсутствует приложенный apply скрипт.
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, и не содержащие своей
программы для приложения патчей. В этом случае для применения
патчей используется встроенный алгоритм из kernel-build-tools
(см. раздел 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 со своим именем
в этом каталоге - этот файл создаётся стандартными функциями из
kernel-build-tools после успешного завершения apply-скрипта.
3.1.3 Макросы для spec-файлов пакетов с патчами
-----------------------------------------------
Поскольку пакет с патчами может включать большое число исходных
файлов, над которыми выполняются однотипные действия, в пакете
kernel-build-tools определены макросы %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/<версия ядра>-<flavour>/*
/usr/include/linux-<версия ядра>-<flavour>/include/*
3.4 Пакет с ядром.
------------------
image:
/boot/config-<версия ядра>-<flavour>-<release>
/boot/vmlinuz-<версия ядра>-<flavour>-<release>
/boot/System.map-<версия ядра>-<flavour>-<release>
/lib/modules/<версия ядра>-<flavour>-<release>/*
headers:
/usr/include/linux-<версия ядра>-<flavour>/*
headers-modules:
/usr/src/linux-<версия ядра>-<flavour>/*
4. Зависимости пакетов
----------------------
4.1 Пакеты с ядром
------------------
Для совместимости со старыми пакетами в пакетах kernel-image-* должны
быть указаны следующие зависимости:
Provides: kernel = %kversion
Provides: kernel24 = %kversion (только для ядер 2.4.x)
Obsoletes: kernel-modules
Obsoletes: kernel-modules-i2c-%flavour
4.2 Пакеты с заголовками ядра
-----------------------------
Пакеты kernel-headers-<flavour> должны иметь следующие зависимости:
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-<flavour> должны иметь зависимость на
соответствующий пакет kernel-headers-<flavour> с точным указанием
версии и сборки:
Requires: kernel-headers-%flavour = %version-%release
4.3 Пакеты с внешними модулями
------------------------------
Пакеты с модулями (kernel-modules-<набор_модулей>-<flavour>) должны
иметь зависимость PreReq на пакет ядра (kernel-image-<flavour>), для
которого они собраны, с точным указанием версии и сборки.
При наличии зависимостей между модулями, содержащимися в разных
пакетах, должны присутствовать соответствующие зависимости (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 должно быть одинаковым, несмотря на
различающиеся имена пакетов).
4.4 Прочие пакеты
-----------------
Никакие пакеты, кроме kernel-modules-* и kernel-complete-*, не должны
иметь зависимостей на пакеты kernel-image-* и kernel-modules-* (как
прямых, так и косвенных через Provides в пакетах kernel-image-* и
kernel-modules-*). В будущем это требование может быть ослаблено
после внесения в apt необходимой функциональности для правильной
обработки зависимостей на пакеты ядра.
5. Порядок приложения патчей при сборке по умолчанию.
-----------------------------------------------------
При построении исходных текстов для сборки spec ядра вызывает макрос
%apply_patches для приложения патчей, который содержится в пакете
kernel-build-tools.
Макрос %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.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20040126/5e9639ba/attachment-0001.bin>
Подробная информация о списке рассылки Devel