Репозиторий Sisyphus
Последнее обновление: 1 октября 2023 | Пакетов: 18631 | Посещений: 37039769
en ru br
Репозитории ALT
S:0.119-alt1
5.1: 0.99.1-alt1
4.1: 0.99.0-alt1
4.0: 0.11-alt1
3.0: 0.8-alt1
www.altlinux.org/Changes

Группа :: Разработка/Прочее
Пакет: kernel-build-tools

 Главная   Изменения   Спек   Патчи   Исходники   Загрузить   Gear   Bugs and FR  Repocop 

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 ядра с
которым собраны модули>. Такие пакеты могут и не существовать, они
требуются лишь в том случае, когда эти заголовочные файлы требуются
для утилит или других модулей.

Если по каким-то причинам необходимо собирать несколько различных
версий одного пакета с модулями (например, в случае, когда в новой
версии есть проблемы с поддержкой старых устройств), для таких пакетов
в имя пакета должна быть добавлена версия:
kernel-modules-<имя_проекта>-<версия_модулей>-<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-complete
--------------------------

Такие пакеты должны называться kernel-complete-<flavour ядра>.

Пакет kernel-complete-<flavour> должен содержать зависимости на
соответствующий пакет с ядром (kernel-image-<flavour>) и на все
собранные для этого ядра пакеты с внешними модулями
(kernel-modules-<набор_модулей>-<flavour>), за исключением пакетов со
старыми версиями модулей, которые конфликтуют с более новыми версиями
аналогичных модулей.

1.7 Пакет 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-* должны быть указаны следующие зависимости:

BuildRequires: kernel-build-tools >= 0.7
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-<flavour> должны иметь следующие зависимости:

BuildRequires: kernel-build-tools >= 0.7
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

Установочные скрипты пакетов kernel-headers-<flavour> должны
содержать:

%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-<набор_модулей>-<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 должно быть одинаковым, несмотря на
различающиеся имена пакетов).

Необходимые зависимости сборки (для макросов, используемых в
установочных скриптах):

BuildRequires: kernel-build-tools >= 0.7

Установочные скрипты пакетов 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 для приложения патчей, который содержится в пакете
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.
 
дизайн и разработка: Vladimir Lettiev aka crux © 2004-2005, Andrew Avramenko aka liks © 2007-2008
текущий майнтейнер: Michael Shigorin