Локальная сборка ISO
Если вам хочется собрать собственный ISO-образ Росы, а доступа для сборки образов на ABF нет, можно собрать образ на локальной машине.
Если нужна сборка корневой системы, а не ISO-образа, то см. статью "Образ rootfs".
Особых требований к системе, на которой запускается сборка, нет, единственное, что мешает ее запускать на дистрибутивах GNU/Linux, отличных от ROSA — это прямой вызов urpmi для создания базового chroot.
Для сборки используются специальные проекты, хранящиеся в Git-репозиториях на ABF и включающие в себя все необходимые для сборки скрипты и вспомогательные файлы. На текущий момент поддерживаются следующие проекты:
- KDE4: soft/build_kde4_desktop_ee
- KDE5: soft/build_plasma5_desktop_ee
- XFCE: soft/build_xfce_desktop
- MATE: soft/build_mate_desktop
- GNOME: soft/build_gnome_desktop
- LXQT: soft/build_lxqt_desktop (устарела и не подходит для текущей версии инструкции)
В каждом репозитории могут быть несколько веток. Основная ветка имеет имя актуальной платформы (rosa2016.1); могут присутствовать и различные дополнительные ветки для тестов и экспериментов. Для начала нужно в любую папку склонировать репозиторий из нужной ветки, пример:
git clone https://foo:bar@abf.io/soft/build_plasma5_desktop_ee.git
Переведем терминал в директорию со скачанными скриптами:
cd build_plasma5_desktop_ee
Теперь можно запускать сборку, пример сборки с минимальным набором параметров, задаваемых переменными окружения:
sudo env TYPES="64u" DE=plasma5 RELEASE=R11 BUILD_ID=20001 ./MATRIX
Обратите внимание, что при запуске скрипта MATRIX терминал должен быть именно в той директории, в которой лежит скрипт MATRIX. В корне этой директории будет создана директория "ROSA.DESKTOP.$RELEASE", которая будет использоваться для раскатывания базового chroot, внутри которого будет запущена сборка с помощью livecd-tools, который сделает еще один чрут внутри существующего чрута. В общем, нужно достаточное количество свободного места. Результирующий образ будет в папке results/, если не задано иное (см. ниже).
Скрипт MATRIX запускается с set -e, из-за чего он завершит свою работу при ошибке на любой промежуточной операции, что упрощает отладку, но может создать некоторые проблемы при сборке в нестандартном окружении. Стандартным условно считаем то, что на ABF.
Смысл переменных окружения (параметров сборки):
- RESULTS_DIR: директория, куда сохранять результирующие образы и логи; по умолчанию создается папка results в текущей директории;
- TYPES: список типов образов, которые будут собираться (возможные варианты: 32, 32u, 64, 64u — соответственно, 32- и 64-битные образы с поддержкой UEFI или без оной); на данный момент можно собирать только один тип за раз, пример: TYPES=64u
- DE: суффикс у файла со списком пакетов, обычно, соответствующий графическому окружению (например, для DE=kde4 будут использоваться файлы commonkde4.lst, i586kde4.lst, x86_64kde4.lst), также $DE войдет в имя файла результирующего образа;
- RELEASE: номер релиза Росы;
- BUILD_ID: номер собираемого образа, может задаваться произвольно;
- MIRROR: зеркало, с которого брать пакеты, пример: MIRROR=http://mirror.rosalab.ru/rosa или MIRROR=http://mirror.yandex.ru/rosa или MIRROR=http://abf-downloads.rosalinux.ru; если не задано, то ставится MIRROR=http://abf-downloads.rosalinux.ru;
- REPO: путь к репозиторию, откуда будут скачиваться пакеты, пример: http://abf-downloads.rosalinux.ru/rosa2016.1/repository/x86_64/, если переменная REPO не задана, то она формируется так: REPO="${MIRROR}/${ROSA_PLATFORM}/repository/${ARCH}/"
Скрипт MATRIX делает следующее:
- устанавливает все обновления на хост;
- средствами urpmi делает chroot с целевой платформой, образ которой собирается;
- заменяет шаблонные вещи типа #ARCH# в файле .ks.template (в .ks.template много чего делается, и на данный момент делается это без set -e, то есть сборка образа не прекращается при ошибке промежуточной команды в .ks.template, что затрудняет отладку);
- в созданном chroot запускает livecd-tools, который собирает образ по .ks.template;
- в результирующий образ добавляется mirror.rosalab.ru в качестве единственного репозитория (то есть сначала собирается образ с тем репозиторием, который вы задали, а потом добавляется другой, без гарантии, что содержимое этих репозиториев одинаковое);
- копирует результирующий образ в $RESULTS_DIR (results/).
Если нужно внести какие-то свои изменения, то потребуется править файлы:
- commonplasma5.lst, i586plasma5.lst, x86_64kplasma5.lst: списки устанавливаемых в образ пакетов (общий список и, при необходимости, архитектуро-зависимые; вместо «plasma5» нужно подставить значение переменной DE);
- i586repo.lst, x86_64repo.lst: дополнительные репозитории или контейнеры (например, если надо собрать образ с тестовой версией пакета, отсутствующей в основном репозитории) (эти контейнеры используются при сборке образа, но НЕ добавляются в качестве репозиториев в результирующий образ!);
- каталог extraconfig: может использоваться для прямого подкладывания или замены файлов в файловой системе образа (кажется, функционал его копирования поломан);
- .ks.template: шаблон Kickstart-файла, используемого для сборки; включает в себя в числе прочего post-скрипты, выполняющие финальную настройку и доводку системы, установленной в образе.
