Структура рабочего каталога

В рабочем каталоге находятся следующие подкаталоги:

kernel

В этом каталоге размещается git-репозиторий ядра.

modules

В этом каталоге размещается git-репозиторий дополнительных модулей.

out

В подкаталог out/logs помещаются логи сборки модулей. Кроме того, при сборке без использования hasher собранные пакеты помещаются в подкаталоги out/RPMS и out/SRPMS.

source

Из этого каталога и его подкаталогов при сборке без использования hasher берутся собранные бинарные пакеты kernel-source-\*, содержащие архивы с исходными текстами ядра и модулей.

tmp

В этом каталоге создаются подкаталоги для временных файлов, используемых при сборке:

tmp/root

Каталог, в который распаковываются бинарные пакеты kernel-source-\* при сборке без использования hasher. Кроме того, в этом каталоге находится база данных RPM, используемая при такой сборке.

tmp/BUILD

Каталог, в котором происходит сборка RPM-пакетов (соответствует макросу %_builddir).

tmp/TMP

Временный каталог для RPM (соответствует макросу %_tmppath).

Данная структура может быть частично переопределена с помощью переменных в файле config.sh (см. раздел “Настройка сборочной среды”).

Подготовка рабочего каталога

  1. Создать каталог и, возможно, файл config.sh для настройки дополнительных параметров сборки: 

    mkdir work
cd work
cp /usr/share/doc/kernel-build-tools-*/config.sh.sample config.sh
$EDITOR config.sh

  2. В подкаталоге kernel необходимо разместить git-репозиторий собираемого ядра: 

    git clone git://git.altlinux.org/people/vsu/packages/kernel-image-2.6.18 kernel
(cd kernel && git fetch origin 'refs/heads/*:refs/heads/*')

  3. В подкаталоге modules необходимо разместить git-репозиторий дополнительных модулей: 

    git clone git://git.altlinux.org/people/vsu/packages/kernel-modules modules
(cd modules && git fetch origin 'refs/heads/*:refs/heads/*')

  4. Для возможности собирать пакеты без использования hasher (что несколько ускоряет работу при выполнении большого количества сборок) необходимо скопировать в подкаталог sources бинарные пакеты kernel-source-\*, содержащие архивы с исходными текстами ядра и модулей. В каталоге sources можно создавать любую структуру подкаталогов — при сборке будут использованы все находящиеся там пакеты \*.noarch.rpm и *.'ARCH'.rpm, где 'ARCH' — выбранная для сборки архитектура. Допускается использование символических ссылок на файлы пакетов (однако символические ссылки на каталоги не обрабатываются).

Скрипты для сборки

buildkernel

Скрипт buildkernel используется для сборки пакета ядра. Сборка может производиться как с использованием hasher, так и без него. Перед запуском этого скрипта в каталоге kernel должен быть размещён git-репозиторий ядра. Кроме того, в случае сборки без использования hasher в каталоге sources должен быть доступен пакет kernel-source-'version'-'release'.noarch.rpm с исходными текстами соответствующей версии ядра; при использовании hasher необходимые для сборки пакеты должны быть доступны в репозиториях APT.

Для сборки ядра необходимо запустить скрипт buildkernel с параметром, в котором указан тип собираемого ядра (flavour):

buildkernel std-smp

При этом для сборки вызывается gear с параметром -t kernel-image-'flavour'.

Дополнительно можно указывать опции:

\--hasher

Сборка с помощью hasher.

\--target=ARCH

Архитектура, для которой собирается ядро.

\--hsh-options=OPTIONS

Дополнительные опции для hsh. Эта строка передаётся в eval, поэтому при необходимости передачи параметров, содержащих пробелы или другие символы, имеющие специальное значение в shell, нужно использовать shell quoting.

\--hsh-workdir=DIR

Рабочий каталог для hasher.

\--rpmbuild-options=OPTIONS

Дополнительные опции для rpmbuild. Эта строка передаётся в eval, поэтому при необходимости передачи параметров, содержащих пробелы или другие символы, имеющие специальное значение в shell, нужно использовать shell quoting.

buildmodules

Скрипт buildmodules предназначен для сборки пакетов с модулями. Сборка может производиться как с использованием hasher, так и без него. В случае сборки без использования hasher в подкаталоге sources должны находиться пакеты с исходными текстами нужных модулей, а в подкаталоге out должны находиться собранные бинарные пакеты ядра, для которого будут собираться модули; при использовании hasher эти же пакеты должны быть доступны в одном из репозиториев APT, используемых hasher.

Вариант ядра (flavour), для которого собираются модули, задаётся через опцию -k 'flavour'; эта опция может быть указана несколько раз, чтобы модули собирались для всех указанных ядер. Имена модулей, которые необходимо собрать, указываются в параметрах скрипта; если параметры отсутствуют, список модулей для сборки берётся из файла modules.build, который должен находиться в ветке kernel-image-'flavour' git-репозитория kernel.

Для совместимости поддерживается старый формат вызова, в котором опция -k 'flavour' не используется, а тип ядра указывается первым обычным параметром (который в этом случае является обязательным); второй и последующие параметры содержат имена модулей для сборки.

Опции, поддерживаемые скриптом buildmodules:

-d, \--distribution=NAME

Задать имя ветви репозитория (по умолчанию используется sisyphus; ветви для обновлений к дистрибутивам именуются в формате alt-linux-'X'.'Y').

-k, \--kernel=FLAVOUR

Собирать пакеты для указанного варианта ядра. Опция может использоваться несколько раз, при этом сборка будет выполнена для всех указанных вариантов ядра.

\--commit

Создать в ветках для окончательных пакетов с модулями (kernel-modules-'MODULE'/'BRANCH') коммиты для собираемых модулей, предназначенные для сборки пакетов с помощью gear.

\--tag

Создать коммиты (как при указании опции \--commit), а также теги вида kernel-modules-'MODULE'/'VERSION'-'RELEASE' для собираемых модулей. Теги создаются утилитой gear-create-tag и подписываются с помощью gpg; для удобства при создании тегов для большого количества модулей можно использовать gpg-agent, чтобы не вводить пароль при подписи каждого тега.

\--no-build

Не выполнять сборку пакетов. Эта опция может быть указана только совместно с \--commit или \--tag.

-f, \--force

Собирать пакеты с модулями заново даже в том случае, если собранный пакет уже есть в out/RPMS, либо в ветке kernel-modules-'MODULE'/'BRANCH' для собираемого модуля уже есть коммит с совпадающими номерами версии и сборки, но с отличающимся содержимым. При использовании совместно с опцией \--tag опция \--force также разрешает замену созданных ранее тегов.

\--hasher

Сборка с помощью hasher.

\--target=ARCH

Архитектура, для которой собираются пакеты.

\--hsh-options=OPTIONS

Дополнительные опции для hsh. Эта строка передаётся в eval, поэтому при необходимости передачи параметров, содержащих пробелы или другие символы, имеющие специальное значение в shell, нужно использовать shell quoting.

\--hsh-workdir=DIR

Рабочий каталог для hasher.

\--rpmbuild-options=OPTIONS

Дополнительные опции для rpmbuild. Эта строка передаётся в eval, поэтому при необходимости передачи параметров, содержащих пробелы или другие символы, имеющие специальное значение в shell, нужно использовать shell quoting.

Настройка сборочной среды

В файле config.sh при необходимости могут быть установлены значения следующих переменных:

rpm_target

Архитектура для сборки пакетов, используемая, если при запуске сборки явно не указана опция \--target='ARCH'. Значение по умолчанию определяется по выводу uname -m, причём для всех вариантов Intel x86 (32-bit) используется i586.

rpm_builddir

Каталог, в котором осуществляется сборка RPM (%_builddir, по умолчанию $TOP/tmp/BUILD).

rpm_tmppath

Каталог для временных файлов RPM (%_tmppath, по умолчанию $TOP/tmp/TMP).

rpm_rootdir

Каталог, в который распаковываются RPM-пакеты, содержащие архивы с исходными текстами ядра и модулей (по умолчанию $TOP/tmp/root).

rpm_logdir

Каталог, в который помещаются логи сборки пакетов с модулями (по умолчанию $TOP/out/logs).

rpm_srcrpmdir

Каталог, в который помещаются собранные src.rpm (по умолчанию $TOP/outdir/SRPMS).

rpm_rpmdir

Каталог, в который помещаются собранные бинарные пакеты (по умолчанию $TOP/outdir/RPMS).

hsh_options

Дополнительные опции, передаваемые hsh. При использовании опции \--hsh-options='OPTIONS' значение этой переменной заменяется значением, переданным в командной строке.

rpmbuild_options

Дополнительные опции, передаваемые rpmbuild. При использовании опции \--rpmbuild-options='OPTIONS' значение этой переменной заменяется значением, переданным в командной строке.

hsh_workdir

Рабочий каталог для hasher. Значение по умолчанию определяется установками переменной prefix в файлах /etc/hasher-priv/system и /etc/hasher-priv/user.d/'USER': используется каталог $prefix/$USER/hasher, кроме случая, когда для prefix установлено значение ~ — тогда используется каталог $HOME/hasher.

Шаблоны модулей

Шаблоны модулей размещаются в репозитории modules в ветках с именами template/'MODULE'/'BRANCH', где 'MODULE' — имя пакета без flavour ядра и kernel-modules-, 'BRANCH' — имя ветви репозитория (sisyphus, alt-linux-4.0, …).

Шаблон spec-файла должен содержать строки вида:

%define module_name     slmdm
%define module_release  alt13
%define module_version  2.7.10

%define kversion        @kversion@
%define krelease        @krelease@
%define flavour         @kflavour@

Name:           kernel-modules-%module_name-%flavour
Version:        %module_version
Release:        %module_release

На самом деле использование именно таких определений макросов не является обязательным — главное, чтобы поля Name/Version/Release в результате получали значения в нужном формате, однако в большинстве существующих шаблонов используются макросы с указанными в примере именами.

При сборке модуля следующие ключевые слова, используемые в шаблоне, заменяются на конкретные значения:

  • @kversion@ — версия ядра

  • @krelease@ — релиз ядра

  • @kflavour@ — flavour ядра

В предыдущем варианте шаблонов также использовалось ключевое слово @kreleasebuild@, которое добавлялось в конец поля Release (обычно в определении макроса %module_release). В текущем формате шаблонов ключевое слово @kreleasebuild@ не используется, и не должно присутствовать в файле шаблона (в случае, если оно присутствует в файле, считается, что шаблон имеет старый формат). При использовании нового формата шаблонов код версии и номер сборки ядра добавляются в конец первой из встреченных строк Release: в шаблоне, после чего вызывается add_changelog для добавления сообщения об автоматической сборке пакета.

В git-репозитории ядра должен содержаться файл modules.build, содержащий список пакетов с модулями, которые необходимо собрать. Например:

$ cat kernel/modules.build
fglrx
nvidia
hostap
drm