Alt linux сборка пакетов

Инструкция по сборке пакетов с помощью rpm

1. Установка необходимых пакетов для процесса сборки

# apt-get install rpm-build

2. Установка src.rpm пакета нужного ПО, которое требуется собрать

Находим и качаем src.rpm пакет нужного ПО, которое будем собирать, и устанавливаем его (от пользователя!):

$ rpm -i название_пакета_с_версией.src.rpm

При этом исходники (исходный код) пакета разместятся в

/RPM/SOURCES , а спек — в

/RPM/SPECS .
Наличие исходного кода программного обеспечения и спека, т.е. описания процесса сборки, является необходимым и достаточным условием для сборки rpm пакета (или пересборки, например, пакета из более нового бранча для более старого).

3. Сборка пакета

Приступаем к сборке, делается это командой:

$ rpm -ba —target (i586|x86_64)

При этом необходимо раскрыть скобки в зависимости от архитектуры, под которую происходит сборка пакета.

Собранные пакеты разместятся в

$ rpmbuild —rebuild —target (i586/x86_64) название_пакета_с_версией.src.rpm

При этом необходимо также раскрыть скобки в зависимости от архитектуры, под которую происходит сборка пакета.

4. Установка сборочных зависимостей

Если имеется srpm пакет, для сборки которого необходимо установить зависимости, то это можно сделать, выполнив следующую команду:

# apt-get build-dep название_пакета_с_версией.src.rpm

Если srpm пакета нет и имеется отдельно спек и исходный код, то почти 100% сборка сразу не пойдёт — в самом начале вывода в консоли будут показаны пакеты, которые должны быть установлены в систему, прежде чем сборка сможет пойти далее. Вы их (эти выведенные в консоль зависимости сборки) установите

# apt-get install пакет1 пакет2 пакет3 .

а после повторите сборку (возврат к шагу 3).

5. Автоматический поиск зависимостей для вновь собираемого пакета

Если вы собираете новый пакет, а не пересобираете уже существующий srpm, то хорошим подспорьем в рамках оформления (поиска и прописывания) нужных зависимостей в спек вам послужит утилита buildreq из пакета rpm-utils :

Источник

Сборка пакета с нуля

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Данное руководство покажет, как правильно собрать пакет RPM в Sisyphus с нуля в инфраструктуре Gear и git.alt, имея только исходный код пакета, и права мейнтейнера на git.alt. В качестве примера опакетим KChildlock, чтобы закрыть запрос на сборку в багзилле: https://bugzilla.altlinux.org/25796.

Содержание

Введение [ править ]

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

1. У вас установлен дистрибутив ALT Linux;
2. Есть желание собрать пакет правильно, а не для единичного случая;
3. Вы носите гордое звание «мейнтейнер ALT Linux Team», что подразумевает наличие электронных ключей и доступа к инфраструктуре git.alt

Третий пункт необязателен для новичков, которые просто хотят собрать пакет правильно для себя.

В ALT Linux используется формат пакетов RPM, который представляет собой архив, содержащий архив с устанавливаемыми или собираемыми файлами и заголовок с метаинформацией (например, название, версия, группа и т.п.). Различают два вида пакетов RPM:

• Пакет с исходным кодом (имеет расширение .src.rpm). Такой пакет содержит архив (один или несколько) с исходным кодом, файл Spec (далее — просто спек) и, возможно, разнообразные патчи и дополнения. Пакет src.rpm можно использовать только для сборки двоичных пакетов, но не установки. Сборка осуществляется командой:

• Собранный двоичный пакет (имеет расширение вида .rpm). В качестве архитектуры может быть i586, x86_64 или noarch. Такие пакеты можно устанавливать командой

Подробную информацию по структуре RPM и сборке с помощью команды rpm можно найти в Maximum RPM.

Однако для сборки через rpmbuild возникают очевидные сложности:

1. Необходимо вручную удовлетворить сборочные зависимости для сборки (поставить компилятор, включаемые файлы, библиотеки). При большом количестве собираемых пакетов система засоряется.
2. Для сборки пакета нужно сформировать .src.rpm из файлов, разбросанных по разным каталогам (по умолчанию, это подкаталоги SOURCE, SPECS и подкаталоги для сборки в

/RPM).

Файлы с исходным кодом должны лежать в упакованном виде, что делает трудоёмким процесс изготовления патчей.

На рабочей системе можно упустить необходимое и достаточное количество зависимостей.

Чтобы избежать этих сложностей, в ALT Linux Team было придумано две технологии:

• Hasher для сборки в изолированном окружении. В chroot ставится базовый комплект пакетов и пакеты, необходимые для сборки (поле BuildRequires в спеке). Если какой-то пакет для сборки не указан в спеке, то появится ошибка. Так обеспечивается чистота сборки. Обратной стороной является необходимость иметь доступ к репозиторию, так как пакеты ставятся при каждой сборке в Hasher.
• Gear для сборки пакетов из репозитория Git. В этом случае все файлы лежат в распакованном виде и в src.rpm упаковываются по правилам, определённым в .gear/rules. Это позволяет работать сразу с содержимым, быстро делать патчи, вести историю изменений и обмениваться изменениями при коллективной разработке.

Установка пакетов для сборки [ править ]

Для сборки нам потребуются следующие компоненты:

• Любой удобный текстовый редактор (наиболее удобными являются Vim и Emacs);
• Система управления версиями Git
• Сборочная среда Hasher
• Инфраструктура Gear
• Доступ к репозиторию пакетов

Для этого настройте репозитории и установите пакеты build-environment и gear:

Будут установлены с зависимостями все необходимые пакеты для опакечивания и сборки

Настройка среды [ править ]

Окружение Git [ править ]

Измените в зависимости от ваших параметров. Третья команда задаёт идентификатор вашего GPG-ключа для подписи:

Окружение RPM [ править ]

/.rpmmacros следующего содержания (конечно, заменив ключ и имя мейнтейнера на свои):

В %_gpg_name указывается отпечаток ключа (а не краткий идентификатор, как для Git). Получить его можно командой:

Окружение Hasher [ править ]

Для начала создайте под правами root двух служебных пользователей для сборочницы (среды сборки Hasher):

Вместо «cas» нужно указать существующего пользователя на машине, где будет развёрнута сборочная среда.

Далее для простейшей конфигурации Hasher потребуется создать каталог

/.hasher со следующими файлами:

Соответственно, USER должен быть такой же, как заведён в hasher-useradd, target — указывать на архитектуру собираемых пакетов.

Подготовка репозитория Git [ править ]

Репозиторий Git создать очень просто. Для этого создадим каталог (имена пакетов лучше указывать в нижнем регистре, поэтому наш пакет для проекта будет называться kchildlock), перейдём в него и запустим git init:

Источник

Сборка проприетарного пакета с нуля

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Данное руководство покажет, как правильно собрать пакет RPM в Sisyphus с нуля в инфраструктуре Gear и git.alt, не имея исходного кода пакета, на примере пакета StarBoardSoftware.

Содержание

Входные требования [ править ]

• Желательно иметь локальное зеркало Сизифа.
• Установленный и немного настроенный hasher[1] .
• Пакет, который необходимо пересобрать для Сизифа.
• Ну, и самое главное, желание этим заниматься.

Исследование пакета [ править ]

Первым делом нужно исследовать пакет на его кривость.

Для начала смотрим список файлов, которые появляются после установки пакета: rpm -qlp StarBoardSoftware-9.2.i586.rpm | less .

И видим, что все файлы ставятся в каталог /usr/local/ .

Попытка установить пакет [ править ]

Пробуем поставить этот пакет в hasher, на голую систему:

hsh —initroot-only -v

/hasher

hsh-install -v `pwd`/StarBoardSoftware-9.2.i586.rpm

Удовлетворение зависимостей [ править ]

Ладно, создаём фиктивный пакет со следующим спеком в

• rpmbuild -bb perl-strict.spec

Ставим наш самособранный пакет в hasher:

• hsh-install -v `pwd`/perl-strict-1.0-alt1.noarch.rpm

Вторая попытка установки [ править ]

Второй подход к установке:

• hsh-install -v `pwd`/StarBoardSoftware-9.2.i586.rpm

Из этого следует, что пакет перед установкой пытается выполнить какой-то скрипт preinst, далее нам не позволяют устанавливать корень системы.

• rpm -qlp StarBoardSoftware-9.2.i586.rpm | less head -n5

Да, действительно почему-то авторы исходного пакета решили упаковать корень. В связи с этим, при установке этого пакета rpm пытается обновить дату создания / .

Посмотрим установочные скрипты пакета. Запускаем mc mc , смотрим содержимое пакета, входя в него, как в архив, сценарии находятся в INFO/SCRIPTS/ во внутренностях пакета. Либо в терминале выполняем команду rpm -qp —scripts StarBoardSoftware-9.2.i586.rpm . Смотрим скрипты, ужасаемся и решаем, что ни в коем случае не следует устанавливать этот пакет как есть.

Зато видим, что в пункте postinstall выполняется команда

• /usr/local/StarBoardSoftware/installation-scripts/install.sh binary uspace app

Здесь-то и находится вся логика установки!

Извлечение файлов из пакета [ править ]

Достаём файлы из пакета без установки:

• rpm2cpio StarBoardSoftware-9.2.i586.rpm | cpio -i

Как мы и ожидали, у нас появился каталог usr .

Для удобства дальнейшей работы упаковываем этот каталог в tar-архив: tar -cvf starboard_usr.tar usr

Исследование лицензии [ править ]

Также исследуем файлы на предмет наличия лицензии. Находим ./usr/local/StarBoardSoftware/Resources/documents/COPYING , который содержит GPLv2. Также находим файл ./usr/local/StarBoardSoftware/Resources/documents/license/ru/license.rtf , который содержит следующие строки:

Значит, можно пакет пересобрать для Сизифа.

Под лицензией GPLv2 поставляется драйвер для доски StarBoard, будем считать, что он уже собран. В отличии от других систем, в ALTLinux скомпилированный драйвер ядра ставится в /lib/modules/`uname -r`/lsadrv/lsadrv.ko .

Автоматизация установки [ править ]

Для множественных попыток установить этот софт в hasher создаём сценарий автоматизации.

Запуск установочного сценария [ править ]

После запуска нашего скрипта получаем следующее.

Смотрим, что добавилось:

Выходит, что во время установки сценарий пытался скомпилировать драйвер и поставить его в /lib/modules/2.6.35-std-def-alt9/kernel/drivers/usb/input , но у него это не вышло. И ещё он решил добавить каталог поиска системных библиотек в /etc/ld.so.conf.d/lsadrv.conf , что не может не вызвать подозрение на нарушение целостности системы.

Смотрим, что там такое:

• cat hasher/chroot/etc/ld.so.conf.d/lsadrv.conf

• ls hasher/chroot/usr/local/lsadrv/lib

Наличие в /usr/local/lsadrv/lib библиотек Qt может пагубно повлиять на системные Qt-программы, если этот путь будет использоваться системой.

Изменённые настройки [ править ]

• grep -a diff hasher/chroot/.out/etc.diff

Отсюда видим, что изменился файл, в котором указывается список загружаемых при старте модулей /etc/modules , также изменился кэш с информацией о системных библиотеках /etc/ld.so.cache . Если первое ещё терпимо, то второе уж точно в данном случае допускать нельзя.

Исправление сценария установки [ править ]

Где что находится [ править ]

Смотрим, где нужно править путь к модулю:

/hasher/chroot/usr/local/StarBoardSoftware

grep -r —binary-files=without-match kernel/drivers/usb/input .

Где возможно отсутствует установка /usr/local/lsadrv/lib в LD_LIBRARY_PATH:

• grep -r —binary-files=without-match LD_LIBRARY_PATH . 2>/dev/null | grep -v ‘/usr/local/lsadrv/lib’ | grep -v export

После изучения скриптов, выясняется, что в ./installation-tools/starboardservice под LSADRV_DEST значится /usr/local/lsadrv , значит это пока править не нужно.

Где вызывается обновление кэша системных библиотек:

• grep -rn —binary-files=without-match ldconfig . 2>/dev/null

Сценарий исправления сценария установки [ править ]

Для исправления сценария используется команда sed с синтаксисом: sed -i «s/что заменить/на что заменить/g» . Переменные $prefix и $sroot ещё установлены в предыдущем сценарии.

Источник

О стратегии сборки RPM пакетов

Содержание

Цель [ править ]

Цель — введение в стратегии сборки RPM пакета «с нуля» при помощи Hasher.

Общие слова [ править ]

Данная статья является дополнением, в чём-то перепевом, статьи Андрея Черепанова — Сборка пакета с нуля. Но по цели и духу эта статья иная. На мой личный взгляд: малополезно описывать сборку какого-то конкретного пакета. Интересен набор практик и подходов к сборке. Я здесь хочу привести возможный способ работы с системой, хочу подчеркнуть особенности, в сравнении с иными материалами о RPM упаковках. Хочу обратить внимание на наиболее тяжёлые составляющие. Не ставлю целью: написать исчерпывающую, пошаговую инструкцию. Выбор и обработка исходного кода-примера неслучайны. Это демонстрация реально возможных отклонений от привычных дилетантам «./configure && make && make install».

Попробую организовать изложение так, что для применения будет возможен прямой copy-paste в командную строку на чистой инсталляции операционной системы (например, в виртуальной машине). В т.ч. с этим и с удобством отладки связанно применение shell переменных в тексте. Раз начав работать, работайте в одном конкретном окне терминала, или нужно будет сделать для каждого терминала повторный ‘export’ для использованных переменных. В ALT Linux семейства P6 команды в терминал нужно копировать и выполнять по одной — тройной щёлк левой кнопкой мышки по строке в тексте, щёлк средней кнопкой в терминал, и Enter. Не занимался исследованиями отчего тут это так можно напороться на свойства параллелизации.

В целом, текст ориентирован на требования коллектива ALT Linux к пакетам, собираемым для официального репозитория. Но есть сознательные отклонения. Останутся они, или кто уделит время их вычистке — мне всё равно.

Части, касающиеся подписывания электронным ключом собираемого пакета, можно пропустить или выпустить из текста. Полные пояснения будут даны не ко всем упоминаемым командам и действиям.

Ниже будет использовано абстрактное имя человека Not Shure, имя пользователя notshure, абстрактные адреса. Подразумевается, надо подставить своё имя вместо имени парня Not Shure и т.п. Подразумевается, что работа идёт от имени этого пользователя.

Сборка описывалась и проверялась для семейства ALT Linux P6, с репозиториями пакетов для P6, для i586 архитектуры.

С точки зрения эргономики, удобно экспериментировать в VirtualBox (использовался 4.1.18 из внешних для ALT Linux источников). Там удобно делать snapshot’ы прямо с запущенной системы, он работает на бывшем, на момент написания, в доступе процессоре. Ключевые точки «на траектории» изменения/настройки системы: конфигурация Hasher, первый запуск Hasher. В виртуальной машине был установлен OpenSSH server, запущен. После чего все действия на виртуалке выполнялись в эмуляторе терминала на машине хозяине, через SSH подключение. Впрочем, виртуальная машина необязательна. Ниже описанное применимо и без неё.

Настройка среды [ править ]

Необходимое в первую очередь ПО устанавливается по команде:

Выбор GPG ключа [ править ]

Иногда, в качестве удостоверения личности используют GPG. Если GPG ключа нет, то можно создать его. Как — см. Работа с ключами разработчика.

Идентификатор ключа для Not Shure, скорее всего, можно увидеть, дав в терминале команду:

Или его можно найти в выводе команды (обр. внимание на строку «sec . «):

Для моего ключа идентификатор 835560D9.

Кроме идентификатора понадобится отпечаток ключа. Отпечаток для ключа ‘835560D9’ доступен по команде:

Для моего ключа отпечаток ‘1B40E49FD40245D0472E4C5FD9528003835560D9’.

Идентификатор и отпечаток понадобятся позже.

Настройка GIT общая [ править ]

Настройте имя, адрес, идентификатор ключа для создаваемых вновь GIT репозиториев:

Окружение RPM [ править ]

Визуально проверьте файл на соответствие ожидаемому:

Окружение Hasher [ править ]

Создайте двух служебных пользователей для сборочницы-песочницы (среды сборки Hasher):

Имя ‘notshure’ это имя существующего пользователя на машине, где будет развёрнута сборочная среда. От этого имени будет вестись(инициироваться) сборка пакетов. После регистрации надо войти-выйти, т.к. было добавление в группу. Для новичков — проще перезагрузиться.

Момент регистрации пользователя и т.п. в Hasher тонки. Не советую ошибаться, а то придётся полопатить код Hasher’а и Интернет.

Есть возможность внести настройки Hasher в специальный файл ‘

/.hasher/config’. Откройте файл на редактирование:

Вставьте туда содержимое:

Однако, ниже будет применена стратегия использования многих песочниц со своими отдельными настройками, вместо одной с «обычным» файлом настроек. Файл с настройками здесь создаётся только ради демонстрации его существования — чтоб был в мыслях, о оптимальных способах организации своей работы.

Добавьте разрешение на создание файловой системы /proc внутри песочницы:

В файл ‘/etc/hasher-priv/system’, открывшийся в редакторе, добавьте отдельную строку:

Если нужно, добавьте туда др. точки монтирования.

Подготовка репозитория Git [ править ]

Создание репозитория [ править ]

Создайте каталог, где будет находиться репозиторий с программой, создайте сам репозиторий:

Далее, если не оговорено иного (в т.ч. через cd и т.п.) и нет ошибки, предполагается, что команды отдаются внутри каталога ‘

Создание веток [ править ]

Совсем необязательно, но удобно, когда оригинальный программный код расположен в отдельной ветке репозитория. Тогда код, в который вносятся изменения, файлы необходимые для сборки RPM пакета располагаются в своих, отдельных ветках. Если в этом нет нужды, то всё касающееся веток, дополнительных к ‘master’, можно пропускать, избирательно.

Например, можно сделать вот такие ветки:

• master — здесь будут находится служебные файлы, используемые при сборке RPM пакета: Spec файлы, файлы Gear (.gear/, и прочее). Программный код может быть, а может и не быть в этой ветке. По выбору собирающего пакет.
• upstream — оригинальный, авторский, распакованный программный код, как он был предоставлен. Этот код будет хранится в этой ветке неизменным.
• devel — ветка, в которую будет скопирован авторский код. Если потребуется вносить изменения в программу, то изменения будут внесены именно в этой ветке.

Наполнение репозитория [ править ]

Создайте необходимые ветки и заготовки файлов:

Можно проверить, что получилось:

GIT сообщает, что текущая(активная) ветка ‘master’ (помечена ‘*’ в выводе первой команды), что в отслеживаемых файлах нет изменений (вторая команда; она же — тоже указано имя текущей ветки).

Написание .gear/rules [ править ]

Забегая вперёд, создайте правило для Gear:

Здесь ‘targetTag’ — некое, пока ещё «волшебное», имя. Это имя будет символизировать какой код, из какой ветки Вы хотите собрать и упаковать в RPM. Есть рекомендации составлять это имя из версии программы и номера сборки. Например: 0.0.1-alt4. Т.е. 0.0.1 — версия программы, alt4 — четвёртая сборка этой версии для ALT Linux. Я здесь выбираю это имя равным ‘targetTag’.

‘hello’ — это имя каталога, в котором будет находиться программный код внутри репозитория. Оно соответствует имени собираемого пакета. Код из этого каталога будет собран и упакован в пакеты.

Импорт исходного кода [ править ]

Простой способ [ править ]

Есть разные способы. Простейший: скопировать программный код в один из каталогов в репозитории.

Откройте для редактирования файл ‘

Внесите в файл содержимое и сохраните:

Это и будет исходный код программы. Внесите в GIT репозиторий каталог с исходным кодом:

Импорт из src.rpm [ править ]

Написание спека [ править ]

На мой взгляд, в Spec две тяжёлые для создания составляющие: 1) определение зависимостей и 2) определение файлов — результата компиляции — которые нужно будет инсталлировать когда-либо. Стандарты есть, но в общем случае всё бывает ооочень по разному.

В Spec файле потребуется указать группу, к которой нужно отнести собираемый пакет. Список групп в файле ‘/usr/lib/rpm/GROUPS’. Например, сейчас там есть группа ‘Development/Other’.

Поиск зависимостей [ править ]

Поиск — занятие творческое. Панацеи нет. Сначала нужно посмотреть, что пишут авторы у себя на сайте, в файлах, приложенных к исходному коду. Это сформирует примерный список нужного.

Теперь можно использовать поиск в репозитории дистрибутива. Это команды:

Найденные зависимости должны быть внесены в Spec файл.

После этого можно пытаться собрать пакет, переходить к следующим разделам этой статьи. Но! Часто бывает — не все зависимости были найдены сборщиком пакета. Тогда, позже надо будет вернуться к редактированию Spec файла. При сборке пакета, в отчётах о ошибках будут упоминаться имена конкретных недостающих файлов. Нужно искать пакеты в которых есть эти файлы. Решать какие из этих пакетов перечислить в Spec файле.

Один из способов поиска — творчески применять выше перечисленные утилиты apt-*. Один из более эффективных способов — смотреть в индексных файлах ‘contents_index’ репозитория. В этих файлах на отдельных строках приведено соответствие полного имени файла из пакета и имени этого пакета.

Пример расположения этих файлов:

• ‘repo-address’, ‘/altair/ALT/*/’ и т.п. это адреса репозитория, описанные в файле ‘/etc/***/apt.conf’.
• ‘repo-name-architecture’, ‘noarch’ — архитектура пакетов в репозитории.
• ‘base’ — имя каталога с искомым файлом.

Репозиториев, обычно, несколько. Индексных файлов будет несколько. Некоторые из файлов размером в сотни Мб.

Искать удобно так:

• сложить все файлы в один каталог под именами вроде contents_index_имя-архитектура-репозитория
• выполнять в этом каталоге команду:

Можно написать скрипт поиска.

А иногда в дистрибутивах (в репозиториях) бывают доступны специальные, «из коробки» готовые к использованию утилиты для поиска соответствий короткого имени файла и имени пакета. Например, утилита ‘apt-file’.

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

Возможно, что проще, иногда правильнее, собрать из оригинального кода дополнительные, отдельные пакеты с недостающими зависимостями. Но не всегда. Панацеи нет.

Есть иной и относительно успешный выход: взять зависимость в виде готового RPM пакета из другого дистрибутива. Например, скопировать из Fedora-Project и т.п. Возможно взять исходный код нужной версии собираемого пакета (*.src.rpm файлы) не авторский, а проработанный кем-то для Fedora-Project. И изначально собирать уже его. IMHO это снижает уровень поддержки пакета, но даёт быстро и дёшево некий результат.

Секция инсталляции [ править ]

При использовании утилиты ‘install’ можно не указывать конечного владельца и группу для инсталлируемого файла. Т.е. вместо

может быть использовано

См. об особенностях Hasher.

О макросах [ править ]

Если нужно узнать какие макросы есть в системе, можно заглянуть в файлы:

Во что разворачивается макрос ‘%make_install’ можно увидеть так:

Система сборки пакета раскрывает макросы в Spec файле, даже если они находятся внутри комментария. Если нужно «выключить» макрос, то делается это аналогично выключению спец.символов в других системах — удвоением, повторением спец.знака ‘%’:

Конкретный пример Spec файла [ править ]

Откройте Spec файл для редактирования:

Внесите туда содержимое:

В Spec файле нужно убирать пробелы в начале строк (см. о ошибке ‘gear: .gear/rules line 1: Empty @version@ «» specified’).

Внесите изменения в репозиторий:

Сборка в Hasher [ править ]

В процессе сборки пакета, на диске будет существовать два важных и очень разных каталога. 1) — каталог с GIT репозиторием, 2) — каталог с песочницей Hasher, в которой будут работать утилиты, собирающие пакет.

Немного ещё слов о GIT [ править ]

GIT репозиторий хранит в себе историю изменения кода. Каждый коммит в репозиторий имеет свой идентификатор — SHA1 хэш, соответствует внесению каких-либо изменений. Можно сказать: каждый коммит соответствует какому-либо состоянию кода в той или иной ветке. Для сборки можно выбрать любое конкретное состояние кода, из любой ветки, указав сборочным утилитам нужный идентификатор коммита. Т.е. можно собирать пакет из кода какой-либо неактуальной и старой версии, всё ещё хранимой как история в репозитории. Или из кода хранимого в ветке, соседней по отношению к содержащей Spec файл. При этом можно оставаться в ветке, где кроме Spec файла и правил Gear ничего нет.

Подготовка репозитория [ править ]

Сборка будет осуществляться из ветки репозитория, содержащей Spec файл, Gear правила — т.е. из ‘master’. Переключитесь на эту ветку:

Перед сборкой нужно определить какое именно состояние кода, из истории в репозитории, нужно собирать — нужно выбрать какой-либо идентификатор коммита. Смотрите вывод команды:

Иногда в разборе истории помощь могут оказать разнообразные визуализаторы истории. Например, утилита gitk.

Например, пусть нужный коммит имеет SHA1 хэш равный ‘086aded4d6144aa8ffa45f52b21abff02ad8e669’. Пометьте этот коммит тегом ‘targetTag’, обновите теги Gear, внесите сделанные изменения в репозиторий:

Здесь идентификатор ‘835560D9’ надо заменить на идентификатор Вашего PGP ключа.

Свяжите текущее состояние ветки ‘master’ c выбранным для сборки состоянием кода (нужны имя ветки. и хэш ранее выбранного коммита):

Теперь, при запуске сборки, система будет собирать и упаковывать состояние кода, помеченное тегом ‘targetTag’. См. ранее о правилах Gear.

Подготовка песочницы [ править ]

Можно собирать пакет в каталоге-песочнице, создаваемом по умолчанию. Удобнее иметь несколько разных каталогов — несколько разных песочниц. Под разные архитектуры, под разные пакеты и разные версии.

Пускай путь к каталогу с песочницей будет «$«. Структура каталогов, файлы в песочнице будут следующими, например:

В каталоге «$» будут храниться файлы, создаваемые в т.ч. по инициативе пользователя, автоматикой он не контролируется. Каталог «$/hasher» — это песочница, в ней будут работать роботы.

Создайте песочницу, откройте для редактирования файлы с конфигурациями, заполните файлы по образцам:

Содержимое файлов см. ниже в приложении. Имя каталога с песочницей в файлах замените на реальное, т.е. менять внутри файлов ‘/directorySandbox’ на вывод команды:

Если в каталоги вида ‘/directorySandbox/hasher/repo/i586/RPMS.hasher’ скопировать какие-либо RPM пакеты, сборочные утилиты могут использовать эти пакеты. Например, в этот каталог можно добавлять пакеты-зависимости отсутствующие в доступных репозиториях. Эти пакеты зависимости будут использованы при сборке (установлены внутри песочницы). Есть алгоритм выбора пакетов-зависимостей из репозиториев. Обычно (Всегда? А apt.*?) выбирается пакет с наибольшей версией.

При установке программ из репозитория в сети, в Интернете, устанавливаемые пакеты сначала скачиваются в кеш на диске, устанавливаются из кеша, некоторое время хранятся в кеше. На базе кеша можно создавать собственные репозитории на диске. Можно настроить кеш на «хранить вечно, хранить всё», использовать в своих целях. См. литературу по APT менеджеру пакетов и RPM репозиториям.

Сборка [ править ]

Конструирование песочницы занимает ощутимое время. Для экономии времени можно использовать такую стратегию: сгенерировать песочницу один раз, при первой попытке сборки; в последующих попытках использовать уже готовую песочницу; GIT репозиторий не засорять пробными версиями Spec файла и т.п., используя параметр ‘—commit’.

Команды сборки выполняются в корневом каталоге GIT репозитория, активная ветка GIT репозитория — содержащая Spec файл и Gear правила.

Первичные команды для создания песочницы и сборки:

Последующие попытки сборки выполняйте командой:

Эти команды — усложнения, к сильнее использующим центральный конфигурационный файл:

Полную очистку через ‘hsh —cleanup-only’ делать совершенно необязательно. Более подробно про команды см. в приложении — внизу страницы, «Файл compile для песочницы.»

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

Многоточия надо заменить на необходимое, см. выше. (Неужели нет иного способа логгировать в файл или иную сущность, удобную для поиска в логе? При необходимости исследований для больших объёмов кода это нужно.)

Обратите внимание, что использован файл конфигурации apt.conf, несовпадающий с указанным в конфигурационном файле Hasher. Это может быть удобно в случае многих песочниц.

При успешном окончании сборки будут выведены, в числе других, сообщения о том, куда и какие созданные RPM пакеты были скопированы.

Замечание: при работе сборщика имеет место ошибка:

Нужно устранить, проанализировать возможные для сборщика аргументы командной строки. Ошибка не критична для получения упакованных в RPM объектов.

Замечание: нельзя исключать, что можно было указывать внешний, отдельный конфигурационный файл. Тогда скрипт ‘compile’ сокращается/упрощается очень значительно.

Исследование результатов сборки [ править ]

Если сборка неудачна, может потребоваться исследовать файлы и т.п. внутри песочницы. Для входа в песочницу используйте команды:

Вторая команда позволяет получить root привилегии внутри песочницы.

Без дополнительных телодвижений нельзя одновременно войти в песочницу и осуществлять какие-то ещё операции Hasher. Однако, запущенное «параллельное» действие не прерывается, а ждёт окончания других операций.

Список инструментов внутри песочницы краток. Имена пакетов с недостающими необходимыми инструментами можно добавить как зависимости сборки в Spec файле — пакеты будут установлены в песочницу. Так же, можно использовать команду ‘hsh-install’ для доустановки пакетов вручную, находясь снаружи песочницы.

Для корректной работы некоторых программ в песочнице необходимо иметь смонтированными внутри песочницы некоторые файловые системы. Например, /proc для Java инструментов.

Сборочные утилиты производят ряд проверок файлов, получаемых при сборке, упаковываемых в пакет. При необходимости исследований некоторые проверки можно отключить. Одно из средств выключения — макросы в Spec файле:

Ещё — можно заглянуть в файлы ‘/usr/lib/rpm/noarch-linux/macros’, ‘/usr/lib/rpm/brp.d/064-verify_elf.brp’, ‘/usr/lib/rpm/verify-elf’.

Можно отключать проверки через аргументы в командной строке для Hasher. Например, вот такой аргумент ‘—no-sisyphus-check=bindir,subdirs,summary’.

Применение Buildreq [ править ]

См. профильные статьи этой Wiki. Мне не сложилось использовать. По мнению авторитетных специалистов: эвристики ошибаются меньше/реже чем человек. /* Не ссылаюсь на имена. */

Отправка в git.alt [ править ]

Процедура, описанная в соответствующих статьях в этой Wiki, вполне не вызвала вопросов.

Приложения [ править ]

Файл apt.conf для песочницы [ править ]

Файл priorities для песочницы [ править ]

Файл sources.list для песочницы [ править ]

В разных окружениях этот файл может быть разным. См. ‘/etc/apt/sources.list’ как пример. См. ‘man sources.list’, можно скопировать из ‘/etc/apt/sources.list.d/alt.list’:

Или другой вариант ниже использует существующие локально на диске репозитории:

Файл compile для песочницы [ править ]

Файл ‘compile’ является скриптом-обёрткой для запуска описанных в статье команд сборки (в т.ч. с указанием архитектуры и т.д.). В каталоге с GIT репозиторием можно создать символическую ссылку на такой файл. Можно создать разноимённые ссылки на файлы-обёртки в разных песочницах и запускать их по мере надобности, не покидая каталог репозитория, без необходимости работы с полными именами файла, из-за местоположения скрипта в другом каталоге.

Источник