О стратегии сборки 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 подключение. Впрочем, виртуальная машина необязательна. Ниже описанное применимо и без неё.

Настройка среды

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

apt-get install build-environment gear

Выбор GPG ключа

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

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

keyId="$( gpg --list-keys | grep -B 1 'Not Shure' | grep "^pub[[:space:]]" )" ; keyId="${keyId#*/}" ; echo "${keyId%%[[:space:]]*}"

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

gpg --list-secret-keys

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

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

LANG=C gpg --fingerprint 835560D9 | grep 'fingerprint =' | tr -d ' ' | cut -d= -f2

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

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

Настройка GIT общая

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

git config --global user.name 'Not Shure'
git config --global user.email 'notshure@localhost'
git config --global user.signingkey '835560D9'

Окружение RPM

Создайте файл ~/.rpmmacros

echo "%packager Not Shure <notshure@localhost>" >> ~/.rpmmacros
echo "%_gpg_name 1B40E49FD40245D0472E4C5FD9528003835560D9" >> ~/.rpmmacros

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

cat ~/.rpmmacros

Окружение Hasher

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

su -

Сразу за тем:

hasher-useradd notshure
exit

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

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

Есть возможность внести настройки Hasher в специальный файл '~/.hasher/config'. Откройте файл на редактирование:

mkdir -p ~/.hasher/
nohup medit ~/.hasher/config 1>/dev/null 2>/dev/null &

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

USER=notshure
#workdir="/tmp/.private/notshure/"
#target=i586
packager="`rpm --eval %packager`"
#apt_config="$HOME/.hasher/apt.conf"
known_mountpoints=/proc
mount=/proc

Сохраните файл.

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

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

su -

Сразу затем:

nohup medit /etc/hasher-priv/system 1>/dev/null 2>/dev/null &
exit

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

allowed_mountpoints=/proc

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

su - c 'systemctl restart hasher-privd'

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

Создание репозитория

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

mkdir ~/hello-git # Каталог-корень GIT репозитория.
cd ~/hello-git
git init

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

Создание веток

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

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

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

Наполнение репозитория

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

mkdir ~/hello-git/hello # Каталог под исходный код программы.
mkdir ~/hello-git/.gear
touch ~/hello-git/.gear/rules
touch ~/hello-git/hello.spec
git add ~/hello-git/.gear/rules ~/hello-git/hello.spec
git commit -a -m "Initial."
git branch upstream
git branch devel

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

git branch
git status

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

Написание .gear/rules

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

echo "tar.gz: targetTag:hello" > .gear/rules
git commit -m "Gear rules inserted." .gear/rules

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

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

Импорт исходного кода

Простой способ

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

Откройте для редактирования файл '~/hello-git/hello/hello.c':

nohup medit ~/hello-git/hello/hello.c 1>/dev/null 2>/dev/null &

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

#include <stdio.h>

int main (void) {
    printf("Hello.\n");
    return 0;
}

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

git add ~/hello-git/hello/
git commit -m "Original source code is imported." ~/hello-git/hello/

Импорт из src.rpm

...

Написание спека

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

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

Поиск зависимостей

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

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

apt-cache search искомое-сочетание1 искомое-сочетание2
apt-cache show имя-существующего-пакета

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

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

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

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

repo-address/repo-name-architecture/base/contents_index
/altair/ALT/Sisyphus/noarch/base/contents_index
/altair/ALT/p6/noarch/base/contents_index

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

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

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

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

grep -r искомая-часть-имени .

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

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

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

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

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

Секция инсталляции

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

install -m755 -o root -g root targetFile %{buildroot}%{_bindir}

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

install -m755 targetFile %{buildroot}%{_bindir}

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

О макросах

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

/etc/skel/.rpmmacros
/etc/skel.ru_RU.CP1251/.rpmmacros
/etc/skel.ru_RU.KOI8-R/.rpmmacros
/home/${USER}/.rpmmacros
/usr/lib/rpm/*
/etc/rpm/*

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

rpm --eval %make_install

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

# экранированный макрос %%configure

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

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

nohup medit ~/hello-git/hello.spec 1>/dev/null 2>/dev/null &

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

%define namePackager Not Shure
%define addressPackager notshure@localhost
%define dateFormated Wed Oct 10 2012

Name: hello
Version: 1.3
Release: alt1

Summary: The hello programm
License: GPLv3
Group: Development/Other

Url: http://mit.edu
Source: %{name}-%{version}.tar.gz
Packager: %{namePackager} <%{addressPackager}>

# Fake dependency. Used as example of syntax, etc.
BuildPreReq: /proc

BuildRequires: gcc
BuildArch: i586

%description
Hello, I love you,
Won't you tell me your name?
Hello, I love you,
Let me jump in your game.

%prep
%setup

%build

%define dirBuild %{_topdir}/BUILD/%{name}-%{version}
%define dirBin %{dirBuild}/%{name}-%{version}
mkdir -p %{dirBin}
gcc "%{dirBuild}/hello.c" -o "%{dirBin}/hello.out"

%install
install -D -m755 "%{dirBin}/hello.out" %{buildroot}%{_bindir}/hello.out
rm -rf %{dirBin}

%files
%{_bindir}/*

%doc hello.c

%changelog
* %{dateFormated} %{namePackager} <%{addressPackager}> %{version}-%{release}
- Initial build for ALT Linux Sisyphus

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

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

git commit -m "Spec file modified." ~/hello-git/hello.spec

Сборка в Hasher

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

Немного ещё слов о GIT

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

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

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

git checkout master

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

git log

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

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

export tagSHA1Sum=086aded4d6144aa8ffa45f52b21abff02ad8e669

Затем:

git tag --force -u 835560D9 -m "Build target tag updated." targetTag ${tagSHA1Sum}

И теперь:

gear-update-tag --all
git commit -a -m "GIT and Gear tags updated."

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

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

git merge -s ours ${tagSHA1Sum}

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

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

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

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

"${pathToSandbox}" (файлы apt.conf, compile, priorities, sources.list)
|-hasher 
|---repo
|-----SRPMS.hasher
|-----i586
|-------RPMS.hasher
|-tmp

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

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

export pathToSandbox="${HOME}/hsh-sandboxes/p6-hello-i586"
mkdir -p "${pathToSandbox}"
mkdir -p "${pathToSandbox}/hasher"
mkdir -p "${pathToSandbox}/tmp"
pushd . > /dev/null
cd "${pathToSandbox}"
touch apt.conf compile priorities sources.list
chmod +x compile
nohup medit apt.conf compile priorities sources.list 1>/dev/null 2>/dev/null &
popd > /dev/null

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

echo "${pathToSandbox}"

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

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

Сборка

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

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

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

ln -s "${pathToSandbox}/compile" compile-p6-i586
./compile-p6-i586 --clean-all
./compile-p6-i586 --build

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

./compile-p6-i586 --rebuild

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

#hsh --cleanup-only ${pathToSandbox}/hasher
#gear --verbose --commit --hasher -- hsh --verbose --lazy-cleanup --mountpoints=/proc --apt-config="${pathToSandbox}/apt.conf" ${pathToSandbox}/hasher
#gear --verbose --commit --hasher -- hsh-rebuild --verbose --mountpoints=/proc ${pathToSandbox}/hasher

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

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

timestamp=$( date '+%Y-%m-%d-%H%M-%S' ) ; gear ... -- hsh ... 2>./error-${timestamp}.log 1>./build-${timestamp}.log ; unset timestamp

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

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

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

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

rpmdb: /home/notshure/tmp: No such file or directory
rpmdb: unable to create temporary backing file

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

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

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

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

hsh-shell ${pathToSandbox}/hasher

Или:

hsh-shell --rooter ${pathToSandbox}/hasher

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

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

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

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

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

%set_verify_elf_method no

Ещё - можно заглянуть в файлы '/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 для песочницы

Dir::Etc::main "/dev/null";
Dir::Etc::parts "/var/empty";
Dir::Etc::sourcelist "/directorySandbox/sources.list";
Dir::Etc::pkgpriorities "/directorySandbox/priorities";
Dir::Etc::sourceparts "/var/empty";
APT::Cache-Limit "67108864";

Файл priorities для песочницы

Important:
    basesystem
    altlinux-release-p6
Required:
    apt

Файл sources.list для песочницы

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

rpm [p6] http://ftp.altlinux.org/pub/distributions/ALTLinux/p6/branch i586 classic
rpm [p6] http://ftp.altlinux.org/pub/distributions/ALTLinux/p6/branch noarch classic

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

rpm file:/altair/ALT/Sisyphus i586 classic
rpm file:/altair/ALT/Sisyphus noarch classic

Файл compile для песочницы

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

#!/bin/bash
#
# Alex Vesev @ ALT Linux, 2012-10-05
#
##

declare -r maintainerName="Not Shure"
declare -r maintainerMail="not.shure@localhost"

declare -r dirSandBoxTop="${HOME}/hsh-sandboxes/p6-hello-i586"
declare -r dirSandBoxHasher="${dirSandBoxTop}/hasher"
declare -r optDirRepoHasher="--repo=\"${dirSandBoxTop}/repo/...\"" # XXX - применение не реализовано.

declare -r archTarget="i586"

declare -r argNoCheck="--no-sisyphus-check"

function showDoc {
    cat "${0}"
}

[ "${#}" == 0 ] \
    && showDoc \
    && exit 1

cliArgument="${1}"
cliOptionName="${cliArgument%%=*}"
cliOptionName="${cliOptionName#--}"
cliOptionValue="${cliArgument#*=}"

case "${cliOptionName}" in
shell|sh)
    hsh-shell --mountpoints="/proc" "${dirSandBoxHasher}"
;;
build|bu)
    gear \
	--verbose \
	--commit \
	--hasher \
	-- ${archTarget} \
	hsh \
	    --verbose \
	    --nprocs=2 \
	    --packager="${maintainerName} <${maintainerMail}>" \
	    ${argNoCheck} \
	    --target=${archTarget} \
	    --lazy-cleanup \
	    --mountpoints="/proc,/dev/pts,/sys" \
	    --apt-config="${dirSandBoxTop}/apt.conf" \
	    "${dirSandBoxHasher}"
;;
rebuild|reb|rebu)
    gear \
	--verbose \
	--commit \
	--hasher \
	-- ${archTarget} \
	hsh-rebuild \
	    --verbose \
	    ${argNoCheck} \
	    --target=${archTarget} \
	    --mountpoints="/proc,/dev/pts,/sys" \
	    "${dirSandBoxHasher}"
;;
install|ins)
    shift 1
    hsh-install "${dirSandBoxHasher}" "${@}"
;;
clean-all)
    hsh --cleanup-only "${dirSandBoxHasher}"
;;
esac

Ссылки

• Краткое руководство по сборке пакета
• Лекция Георгия Курячего "Демонстрация сборки пакета" (видео, ogv): [1]