Привет, Хабр! На связи команда авторов совместной лаборатории ЛЭТИ и YADRO. Часто компаниям нужно контролировать программное обеспечение в инфраструктуре, включая серверы и ПК сотрудников. А еще — управлять версиями ПО из пакетной базы дистрибутивов, особенно для частных систем, где требуются определенные версии. Здесь компании могут либо довериться стороннему вендору, либо разработать собственный дистрибутив.

Кастомизация дистрибутивов особенно актуальна при разработке встраиваемых устройств, таких как IoT, где требуется собственная инфраструктура для сборки загрузочных образов ОС и полный контроль над процессом. 

В этой статье мы рассмотрим технологии создания загрузочных образов и инфраструктуры для поддержки собственных дистрибутивов на базе Linux, исследуем системы сборки, в том числе Yocto Project, Buildroot и Open Build Service, а также подскажем, как выбрать лучшее для вашего проекта. 

Обзор и классификация решений

Рассмотрим технологии создания дистрибутивов для встраиваемых систем и серверов/настольных ПК. У каждой системы есть свои особенности, и подходы к разработке дистрибутивов будут различаться.

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

Настольные и серверные дистрибутивы могут позволить себе больше избыточности. У них достаточно ресурсов для хранения различных программных компонентов. Процесс установки таких дистрибутивов обычно проще: можно установить минимальный набор компонентов, а остальные загружать по мере необходимости через сеть. Кроме того, нет нужды вручную настраивать драйверы — дистрибутив может содержать множество драйверов для разных устройств и поддерживать функции Plug&Play.

При выборе дистрибутивов мы обращали внимание на системы сборки, используемые для их разработки. Это важно, чтобы рассмотреть как можно больше различных инструментов. Мы решили разделить дистрибутивы на два класса из-за их принципиально разных назначений: desktop и embedded.  

Поиск решений основывался на двух принципах:

• искали готовые дистрибутивы для разных систем, чтобы определить базовые технологии их создания (таблица 1).

• искали инструменты для создания собственного дистрибутива (таблица 2).

В таблице ниже — список найденных нами дистрибутивов с указанием классов и систем сборки, используемых для их создания.

Таблица 1. Классификация дистрибутивов и список систем сборки

Некоторые операционные системы в таблице не относятся к семейству Linux — их рассматривать мы не будем. Многие из существующих решений используют скрипты на базе Make, CMake или Bash без комплексной системы конфигурации под разные ядра и содержимое корневой файловой системы. Поскольку такие подходы — не системные решения для построения дистрибутива, в статье мы их рассматривать не будем.

В списке также есть системы, которые позволяют собирать пакеты только определенного формата: Arch Build System (для пакетов Arch), Solbuild (для пакетов Solus Linux), Abuild (для пакетов Alpine Linux). Эти утилиты не позволяют создать итоговый дистрибутив в виде образа, поэтому их мы также исключим из повествования. Koji (для пакетов RPM) позволяет создавать различные типы образов: live-образ для установки, образы диска и контейнера. Однако это тоже не комплексное решение для построения дистрибутива, поэтому рассматривать мы его не будет.

В следующей таблице — список утилит и систем сборки, которые были найдены отдельно от дистрибутивов. В нем мы не рассматриваем: 

• Android build system, так как система сборки нацелена только на Android-системы, в ней нет централизованной системы конфигурации. И основана она на множестве конфигураций в отдельных подсистемах в виде Makfile-файлов. Подход достаточно трудоемкий и негибкий, поскольку для изменения и расширения проекта на базе android build system может понадобится модификация значительного количества файлов проекта.

• mic, так как это часть Open Build Service.

Таблица 2. Системы сборки для дистрибутивов

Коллеги из YADRO проводят System Level Meetup. Участники глужбе изучат ядро Linux вместе с ведущими разработчиками из Сбера, Syntaocore, YADRO и других компаний. Ознакомиться с программой и подать заявку на участие можно по ссылке.

Desktop-системы: принципы работы и архитектура

OSBuild

OSbuild (или RHEL Image Builder) — система для создания образов ОС, основанных на RHEL. Можно создать образы iso, образы для QEMU, VMWare (qcow2, ova, vmdk). Соответственно, запуск созданного дистрибутива возможен как на виртуальной машине, так и на железе. 

Проект конфигурируется с помощью Blueprint — файлов в формате TOML. В них можно выбрать базовый дистрибутив и его версию, редактировать список пакетов (добавить пакеты из репозитория дистрибутива, добавить собственные репозитории с пакетами), описать файловые системы, таблицы разделов, добавлять пользователей и группы. 

OSBuild разрабатывает компания Red Hat, на ней создавался RHEL и дистрибутивы на его основе.

Архитектура системы

В целом схема работы схожа с Open Build Service, которую мы рассмотрим далее.

Особенности решения

• Подходит для проектов по созданию дистрибутивов на основе уже существующих — например, Fedora, RHEL.

• Предлагает мощные инструменты для создания модульных и повторно используемых конфигураций образов.

• Кастомизация ограничена: инструменты OSBuild фокусируются на сборке файловых систем и конфигурации на основе стандартных RPM-based решений, что делает ее менее гибкой в настройке ядра по сравнению с другими платформами.

Open Build Service

Open Build Service — платформа для создания и распространения бинарных пакетов для различных дистрибутивов Linux и их образов. Проект ведет команда openSUSE Linux, в настоящее время Open Build Service применяется как основная система для разработки openSUSE и SUSE Linux Enterprise. Работать с системой можно на сайте проекта и с помощью утилиты osc. 

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

Альтернативное решение — развернуть собственный сервер сборки, чтобы обеспечить независимость от разработчиков OBS. 

Архитектура системы

Система по принципу работы напоминает систему контроля версий, например git. Клиент локально создает проект с необходимыми скриптами и spec-файлами для сборки пакета, а затем отправляет результат на сервер, где уже происходит сборка и добавление в пакетную базу. Таким образом можно создавать собственную пакетную базу или модифицировать существующую.

Особенности решения

• Поддерживает создание собственных репозиториев и пакетов, включая расширение базовой системы за счет кастомных библиотек.

• Позволяет разрабатывать RPM-based-, DEB-based-системы, а также собственные конфигурации.

• Хотя OBS обеспечивает гибкость в добавлении пакетов и управлении загрузчиком, настройки ядра ограничены.

Debian Build Toolchain

Debian Build Toolchain — это набор инструментов для разработки Debian-пакетов. Утилиты в составе используются для разработки программного обеспечения для Debian и дистрибутивов, основанных на нем. В основном это утилиты для создания и редактирования пакетов, dpkg-dev и build-essential. 

Можно также выделить Debootstrap, который предназначен в первую очередь для установки Debian на хост или работы с ним в chroot-окружении. Утилита не предназначена для сборки пакетов — лишь для установки из репозиториев Debian или других.

Архитектура системы

Так как Debian Build Toolchain не подразумевает централизованной сборки системы, а содержит только набор утилит, обобщенной схемы для описания процесса сборки образа или же устройства проекта нет.

Ниже приведем список утилит. Он неполный, но содержит основные утилиты для создания пакетной базы исходных файлов, пакетной базы бинарных файлов, инсталляции пакетов в образ системы. 

dpkg-пакет предоставляет низкоуровневую инфраструктуру для управления установкой и удалением пакетов программного обеспечения Debian:

• dpkg — утилита для установки, удаления пакетов и управления ими.

• dpkg-deb — утилита для упаковки/распаковки .deb-архива и предоставления информации об архиве.

• dpkg-divert — утилита для изменения путей установки пакета (используется в случае конфликтов пакетов или в других ситуация, когда нужно изменить пути установки).

• dpkg-maintscript-helper — утилита, созданная для выполнения дополнительных задач, которые не решаются утилитой dpkg, для поддержки и сопровождения пакетов.

• dpkg-query — утилита для получения информации о пакете в пакетной базе.

• dpkg-split — утилита для разделения бинарного пакета на более маленькие (используется для передачи данных больших пакетов, если нужно передать пакет частями).

• dpkg-statoverride — утилита для управления правами доступа файлов в пакете.

• dpkg-trigger — утилита для вызова триггеров с помощью dpkg, если они поддерживаются.

• update-alternatives — утилита для управления ссылками на программы по умолчанию (в случае множества версий программ можно указывать версии вызова по умолчанию в командной строке).

dpkg-dev — набор утилит для распаковки, создания, сборки пакетов с исходным кодом.

• debuild — утилита для пересборки deb-пакета.

• build-essential — набор пакетов, включающий dpkg-dev, а также компилятор gcc, g++, libc, make.

• debootstrap — утилита для сборки и установки пакета в другую debian-систему с помощью chroot.

• apt-get — система управления пакетами.

Особенности решения

• Обеспечивает базовую функциональность для разработки и сборки deb-пакетов.

• С помощью debootstrap позволяет устанавливать кастомизированные пакеты.

• Представляет собой набор утилит для создания собственного дистрибутива Debian.

• Требует разработки скриптов для автоматизации процессов.

Alt mkimage (Sisyphus)

Sisyphus (Сизиф) — это проект ALT Linux Team, цель которого — развитие репозитория свободного ПО.

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

• репозиторий ПО (rpm и src.rpm-пакеты),

• инструментарий для подготовки и тестирования программных пакетов (hasher, gear, git; sisyphus_check, qa-robot, repocop и других,

• инструментарий обеспечения целостности репозитория (apt),

• инструментарий для разработки конечных решений, в частности дистрибутивов (mkimage, Alterator, Installer).

Alt mkimage — набор утилит для создания образа на базе ALT Linux и репозитория Сизиф.

Архитектура системы

mkimage — такой же набор утилит, как и Debian Build Toolchain. Он содержит следующие компоненты:

• hasher — средство воспроизводимой сборки пакетов в изолированном окружении,

• gear — инструмент для хранения исходных текстов в git и извлечения заданной версии,

• mkimage — набор утилит для создания образов (в основном ISO),

• mkimage-profiles — метапрофиль (шаблоны для создания профиля сборки) со множеством готовых «кирпичиков» и конфигураций образов.

Базой для построения собственного дистрибутива с помощью системы выступает репозиторий mkimage-profiles, так как именно он содержит скрипты для создания образа и множество готовых конфигураций. 

Структура проекта:

• В conf.d/*.mk описывается конфигурация конкретного типа дистрибутива. То есть это совокупность конфигураций пакетов, поддерживаемых функциональных особенностей — например, для сервера или мобильной системы. По сути это описание отдельного дистрибутива и типа его распространения (загрузочный или live-образ). Эти конфигурации могут пересекаться и наследоваться.

• Субпрофили — базовые комплекты конфигурации способа распространения образа, находящиеся в sub.in/.

• Законченные блоки функциональности (или наборы таковых) описываются в индивидуальных features.in/*/config.mk. Пример такого блока — поддержка конкретной аппаратной платформы (платы), стека определенных технологий.

• Списки пакетов, которые можно включить в сборку, содержатся в /pkg.in директории проекта. Функциональные блоки могут включать пакеты, но не рекомендуется создавать отдельный функциональный блок для добавления пакета.

• В /image.in содержатся файлы, которые просто копируются в итоговый собранный профиль. То есть, когда конфигурация закончена, в окружение для сборки копируются файлы из этой директории. Это необходимо для наложения патчей в других частях профиля, добавления в образ уже готовых файлов.

• В /bin и /lib содержится набор вспомогательных скриптов, реализующих сборку по правилами, которые описаны в конфигурациях. 

Репозиторий можно расширить собственными файлами конфигурации по аналогии с Bitbake, только с помощью Makefile. То есть решение достаточно гибкое, но конфигурировать тулчейн без добавление собственных модификаций не получится.

Особенности решения

• Хорошо подходит для создания безопасных систем, так как пакетная база нацелена на развитие открытого ПО и максимально быстрое устранение критических уязвимостей.

• Поддерживает только rpm-пакеты.

• Требует разработки скриптов для автоматизации процессов.

• Позволяет создавать собственные пакетные базы.

Embedded-системы: принципы работы и архитектура

Yocto Project

Yocto Project — открытая платформа, ориентированная на создание, настройку и поддержку собственных дистрибутивов Linux для встраиваемых систем. Yocto Project предоставляет набор инструментов для создания Linux-дистрибутивов, адаптированных под различные архитектуры и требования, связанные со спецификой того или иного проекта.

Платформу разрабатывают при взаимодействии с Linux Foundation. Система применяется в различных проектах, например для разработки встраиваемых систем для автомобилей. В частности, Yocto используется для разработки Automotive Grade Linux, который используется в большинстве японских автомобилей, также систему применяют в BMW и Ford Motor Company.

Основные компоненты системы включают Bitbake, OpenEmbedded и Poky.

• Bitbake — инструмент сборки, ответственный за сбор и настройку всех компонентов.

• OpenEmbedded — коллекция метаданных и рецептов для сборки пакетов, предоставляющих универсальные шаблоны для конфигурации собственных дистрибутивов.

• Poky — эталонная система, сочетающая инструменты Yocto и OpenEmbedded, которая позволяет разработчикам быстро создавать образы для конкретных устройств. По сути это отдельный дистрибутив, который предоставляет ряд уже разработанных слоев поддержки технологий. Например, есть слои для поддержки Python, PipeWire, различных тулчейнов. На базе них можно создать кастомизированный образ ОС с нужным сочетанием пакетов и настроек.

Архитектура системы

Этапы создания образа ОС: 

1. Настройка образа: набор и версии пакетов, конфигурация ядра, целевая платформа, используемый кросс-компилятор, конфигурации пользователей и т.д.

2. Добавление в сборку уже созданных слоев для поддержки всей конфигурации. Чтобы не изобретать велосипед, лучше изучить как официально поддерживаемые слои, так и сторонние — они уже могут содержать необходимые компоненты. Без добавления таких слоев, согласно созданной конфигурации, невозможно завершить сборку успешно, так как в конфигурации могут быть выставлены параметры, которые не реализуются дистрибутивом poky. Например, в слоях poky не содержится какой-то пакет с именем important-package, но он включен в конфигурацию — это приведет к ошибке. Для ее исправления необходимо добавить слои, где данный пакет присутствует.

3. Модификации уже существующих слоев/рецептов с помощью .bbappend-файлов, которые позволяют добавлять патчи или же изменять параметры определенного  компонента — например, флага компиляции пакета. Реализуется с помощью добавления собственного слоя. Это удобно, так как изменения накладываются поверх исходных слоев, и это позволяет разграничить оригинальные версии пакетов от измененных.

4. Разработка своих слоев для добавления отсутствующей функциональности.

Этапы процесса сборки:

1. Парсинг рецептов.

2. Построение графа зависимостей задач, который определяет последовательность их выполнения.

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

4. Генерация пакетов для установки в корневую файловую систему.

5. Возможна валидация собранных пакетов с помощью специальных механизмов — рассылка по почте для уведомления о новой версии или запуск автоматических юнит-тестов.

6. Создание итогового загрузочного образа.

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

Особенности решения

• Высокая сложность на начальном этапе из-за количества инструментов и зависимостей.

• Большие возможности для конфигурации и дополнения существующих конфигураций без изменения кода проекта за счет системы слоев.

• Большие возможности для сборки пакетов, так как для Bitbake уже существует множество слоев, реализующих тулчейны для разных систем сборок проектов и компиляторов (cmake, make, meson, go, rust), в том числе под разные языки программирования.

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

• Возможности для CI/CD.

Buildroot

Buildroot — это система сборки дистрибутивов для встраиваемых систем, которая представляет собой набор файлов Makefile. Конфигурация и сборка дистрибутива осуществляется командами make. Система предоставляет большой выбор опций для настройки собираемого дистрибутива, в том числе конфигурацию ядра, файловую систему, добавление пакетов. 

Buildroot разрабатывает некоммерческая организация Buildroot Association. За развитием проекта можно следить на GitLab. Наиболее известный проект, для разработки которого используется Buildroot, — OpenWRT.

Архитектура системы

В основе Buildroot лежат Makefile, которые реализуют загрузку, сборку проектов и загрузочных образов. Каждый пакет представляется набором файлов, которые содержат версии, ссылки для загрузки и скрипты для сборки, установки артефактов. Владея базовыми навыками bash и Makefile, достаточно просто модифицировать ссылки на исходный код проекта. В некоторых ситуациях (если инфраструктура сборки пакета изменилась с версией) необходимо переписывать и части, отвечающие за конфигурацию и сборку проекта.

Особенности решения

• Множество поддерживаемых платформ и уже реализованных конфигураций для сборки пакетов.

• Позволяет полностью конфигурировать образ.

• Использует широко распространенный Make для сборки, что упрощает изучение устройства проекта Buildroot.

• Предусмотрены возможности для CI/CD-интеграции.

ELBE

ELBE (Embedded Linux Build Environment) — система сборки, используемая для встраиваемых систем. Система позволяет создавать дистрибутивы на основе Debian. Сборка производится внутри виртуальной машины. Создаваемый образ описывается в XML-файле, в котором возможна конфигурация и редактирование различных параметров (выбор целевой архитектуры, выбор версии дистрибутива, конфигурация файловой системы, добавление дополнительных пакетов и репозиториев, в том числе и своих). ELBE разрабатывает компания Linutronix, которая в данный момент принадлежит Intel.

Архитектура системы

Архитектура ELBE основана на сборке образа в виртуальной машине с помощью libvirt и QEMU. Вся логика сборки и установки пакетов написана на Python. Все конфигурации представлены в виде XML с четко структурированными полями для конфигурации. ELBE реализуется как монолитная система, где нельзя расширить функциональность системы без модификации исходного кода. Все возможности реализуются через отдельные репозитории с пакетами и конфигурацию в виде XML-файла.

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

Особенности решения

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

• Плохо масштабируется, если необходимо доработать или расширить проект.

• Использует готовую пакетную базу Debian, что упрощает включение многих пакетов в образ.

Isar

Isar — система сборки, представляющая собой набор скриптов для создания пакетов и дистрибутивов на базе Debian с возможностью настройки. Организация проекта Isar похожа на Yocto Project, для сборки используется Bitbake. Перед сборкой можно настроить параметры файловой системы, ядра, модификации списка пакетов (добавление и удаление пакетов, в том числе и собственных, изменение существующих пакетов). Систему сборки разрабатывает компания ilbers GmbH.

Архитектура системы

Так как Isar основан на Bitbake, архитектура решения состоит лишь в нескольких слоях для Bitbake, реализующих сборку и установку пакетов в соответствии с конфигурацией сборки. В основе всех этих слоев и рецептов лежат утилиты Debian Build Toolchain, которые ответственны за непосредственную сборку пакетов, разрешение зависимостей и т.д.

Особенности решения

• Аналогично Yocto требует усилий на начальных этапах для освоения инструмента.

• Поддерживает загрузку готовых пакетов из репозиториев Debian.

• Подходит для embedded-дистрибутивов, где необходимо сочетание Debian-экосистемы и глубокой конфигурации.

PTXdist

PTXdist — система сборки для встраиваемых систем Linux. Система собирает дистрибутив из исходного кода и создает образ. PTXdist позволяет выбрать целевую архитектуру процессора, версию ядра, добавить пакеты в сборку (в том числе свои пакеты и репозитории), выполнять настройку файловой системы, выбирать загрузчик операционной системы. Поддерживается разработка для архитектур ARM, x86, PowerPC. Для поддержки других архитектур необходимо установить сторонние тулчейны для кросс-компиляции, при этом конфигурация платформы должна поддерживать этот тулчейн.

PTXdist разрабатывает компания Pengutronix.

Архитектура системы

PTXdist состоит из базового проекта и набора конфигураций DistroKit под различные платформы. Есть широкий спектр тулчейнов в собственной пакетной базе,набор утилит для создания конфигурации под конкретную платформу. Также в проекте есть свой репозиторий с пакетами, который содержит различные тулчейны под разные версии самого PTXdist. Другой репозиторий DistroKit содержит уже готовые конфигурации с описанием пакетов, конфигураций целевых плат — например для Raspberry Pi и т.д.

PTXdist позволяет конфигурировать debug- и release-версии образа, сконфигурировать набор пакетов, которые будут включены в образ, а также непосредственно тип создаваемого образа, ядро.

Особенности решения

• Простая структура и эксплуатация.

• Мало готовых к включению пакетов.

• Мало конфигураций для целевых платформ.

• Широкий выбор различных тулчейнов.

Сравнение функциональных возможностей Desktop- и Embedded-систем сборки

Сравнение Desktop-систем сборки

Desktop-системы сборки фокусируются на создании, поддержке и расширении пакетной базы под ограниченное количество архитектур. Такие системы не требуют поддержки множества разных аппаратных платформ, поэтому они возможностей для конфигурирования ядра Linux у них немного. При этом результирующими образами зачастую бывают образы для виртуальной машины или live-образы. 

Также отметим высокую степень развития платформ OSBuild и Open Build Service. Рассмотренные проекты представляют собой широкий комплекс программных средств, включающих фронтенд с интерфейсом через браузер или утилиту командной строки для управления пакетной базой и удобного создания образа. Несмотря на то, что Alt mkimage и Debian Build Toolchain — не комплексные проекты, но предоставляют целый спектр утилит для быстрой разработки собственных систем управления пакетной базой.

Desktop-системы сборки нацелены на создание пакетных баз под малое количество архитектур. А с помощью уже собранных пакетов можно создавать образы ОС. Embedded-системы, в свою очередь, требуют широких возможностей для внесения правок в пакеты и ядро Linux. Они лучше интегрируются с виртуальными машинами, так как лежат в основе разработки и тестирования ПО для многих встраиваемых систем. Задачи обеих систем отличаются, что явно видно в направлениях их разработки.

В первую очередь системы сборки можно разделить на типы поддерживаемых дистрибутивов. В целом между дистрибутивами нет разницы, кроме содержимого пакетных баз. Ключевое различие — в системах управления пакетами. Самые распространенные — deb- и .rpm-пакеты. OSBuild, Alt mkimage поддерживают только .rpm-пакеты. Open Build System поддерживает многие из уже названных форматов, но также позволяет использовать рецепты других форматов — например, KIWI, simpleimage, Mkosi, flatpak. Debian Build Toolchain нацелен только на deb-пакеты.

Самая большая поддержка различных аппаратных архитектур у Alt mkimage и Debian Build Toolchain, но эти системы трудно автоматизировать, ресурсы «съест» и поддержка их пакетных баз. В свою очередь, они более гибкие в конфигурации образа и ядра Linux.

Сравнение Embedded-систем 

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

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

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

PTXdist — достаточно простой в эксплуатации проект, по структуре похож на Buildroot. Проект активно обновляется, но пока содержит немного готовых конфигураций. Это значит, что конфигурацию придется делать самостоятельно с нуля. А при необходимости — добавлять пакеты, так как сейчас в PTXdist реализуется порядка 900 пакетов. Для сравнения, у Buildroot — более 3000 пакетов.

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

Как выбрать инструмент под свои задачи

Выбор системы сборки зависит от множества факторов, но его можно представить в виде упрощенного дерева решений.

Основные вопросы, которые влияют на выбор:

• Требуется ли поддержка широкого спектра архитектур процессора.

• Нужна ли собственная пакетная база.

• Нужна ли поддержка различных аппаратных платформ.

• Требуется ли CI/CD-интеграция для долгосрочной поддержки дистрибутива.

• Какие предъявляются требования по типу пакетного менеджера.

Если требуется поддержка разных архитектура, а перечисленных в списках для Desktop не хватает, то есть нужда лишь в собственной пакетной базы для контроля всего исходного кода дистрибутива. Если нет требований к контролю за кодом, то Yocto хорошо решает задачи создания одинаковых кастомизированных образов под разные архитектуры. Иначе необходимо разрабатывать собственное решение или модифицировать существующие.

Тип пакетного менеджера также может сильно ограничить выбор системы сборки, так как в первую очередь это влияет на используемую пакетную базу (репозиторий с пакетами) и на характеристики создаваемого дистрибутива. Например, пакетные менеджеры .deb и rpm используют разные подходы к управлению зависимостями. Как следствие, могут возникать различные конфликты зависимостей. Также у самих типов пакетов разные возможности для их валидации (проверка линтером, тесты при установке пакета в систему). В статье мы не рассматриваем вопросы управления пакетами в системе, поэтому выбор конкретного типа пакета остается за вами.

Desktop-системы

Если нужно разработать серверный, настольный дистрибутив или дистрибутив специального назначения для архитектур amd64, aarch64, наиболее удобным и простым решением станет Open Build Service. Система позволяет достаточно легко управлять пакетами и создавать новые, а еще — поддерживает наибольшее количество типов пакетов. Решение универсально для создания своей пакетной базы.

OSBuild подходит для создания rpm-based-дистрибутивов. 

Alt mkimage и Debian Build Toolchain требуют больших усилий для автоматизации процессов, но оставляют возможности для создания более гибкой системы контроля и управления пакетами, конфигурацией ядра Linux.

Embedded-системы

Если необходим широкий спектр разных аппаратных платформ и различных конфигураций, то Buildroot и Yocto хорошо справятся с задачей, минимизируя необходимую работу, если инструменты уже освоены разработчиками дистрибутива. Эти системы позволяют относительно легко автоматизировать тестирование и построить процессы CI/CD.

Для быстрого создания работающих образов ОС под встраиваемую систему подходят ELBE, Buildroot, PTXdist. Но у PTXdist скромное количество пакетов и готовых конфигураций, что потребует дополнительной разработки, если подходящей конфигурации нет. С ELBE создать новую конфигурацию просто, но есть ограничения для кастомизации образа, а тип пакетов ограничен deb-форматом. Конечно, это не проблема, если достаточно кастомизировать скромное количество пакетов и настроек системы, а тип пакетов не имеет значения. Buildroot — самая простая и широко распространенная система для быстрого создания работающего дистрибутива на встраиваемой системе без привязки к пакетной базе.

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

Isar, в свою очередь, наследует от Yocto все харакетристики, но ограничивается пакетной базой Debian. Это плюсом за счет количества пакетов, но минус при необходимости кастомизации или построения дистрибутива с помощью другого пакетного менеджера.

Есть множество различных решений для создания собственных сборок ОС и пакетных баз. Не существует одного универсального решения — каждая из рассмотренных в статье систем ориентирована на несколько задач. Если ставится задача постоянного обновления пакетов, чтобы поддерживать как можно больше разных сервисов, то она сводится к созданию пакетной базы. Тут прежде всего могут подойти Alt mkimage, Debian Build Toolchain, OSBuild, Open Build Service. Наиболее универсальным и простым, на наш взгляд, выступает решение Open Build Service.

Если же необходимо поддерживать какую-то одну конкретную аппаратную платформу, а существующие дистрибутивы под нее по каким-то причинам не подходят, то выбор обычно сводится к наличию уже готовых сборок.Если открытых решений нет, то стоит начать с Buildroot, особенно если нет необходимости добавлять специфичные пакеты.

Если же нужна полная конфигурируемость системы или поддержка большого количества аппаратных платформ, выбор, конечно, сводится к Yocto Project. За счет Bitbake можно разделять конфигурации разных платформ, делать разные версии пакетов с аппаратно-зависимыми патчами и т.д. Это позволяет легко переносить сборки между схожими аппаратными платформами и легко конфигурировать образ на свой лад. Но, конечно, система требует изучения и достаточно много времени, чтобы легко выполнять все возникающие задачи.

Если у вас остались вопросы о создании дистрибутивов, задавайте их в комментариях. Ответят авторы статьи — студенты и преподаватели СПБГЭТУ «ЛЭТИ»:

• Гаврилов Андрей Владимирович, аспирант кафедры МОЭВМ.

• Тиняков Сергей Алексеевич, магистрант кафедры МОЭВМ.

• Карасев Максим Алексеевич, студент программы специалитета кафедры ИБ.

• Казаков Вадим Дмитриевич, студент программы специалитета кафедры ИБ.

• Омуралиев Эскендер Элбекович, студент программы бакалавриата кафедры МОЭВМ

• Заславский Марк Маркович, заместитель заведующего кафедрой МОЭВМ.