Справочник по Yocto Project

Scott Rifenbark

Scotty’s Documentation Services, INC

<srifenbark@gmail.com>

Разрешается копирование, распространение и изменение документа на условиях лицензии Creative Commons Attribution-Share Alike 2.0 UK: England & Wales, опубликованной Creative Commons.

Этот документ основан на переводе Yocto Project Reference Manual для выпуска 2.7.1. Свежие версии оригинальных документов можно найти на странице документации Yocto Project. Размещенные там материалы более актуальны, нежели включенные в архивы пакета Yocto Project.

Глава 1. Системные требования

В этом документе приведена справочная информация для текущего выпуска Yocto Project (YP). Документ лучше изучать после знакомства с основами YP. Здесь приведены определения переменных, классов и других элементов, применяемых в YP.

Вводную информацию о YP можно найти на сайте Yocto Project Website и в разделе Yocto Project Development Environment [1].

Если вы хотите использовать YP для быстрой сборки образа, не разбираясь в деталях и концепции, работайте с документом [5]. Документация по отдельным операциям представлена в [2], а обзор и концепции YP – в [1].

Дополнительные сведения о документации YP приведены в разделе Литература.

1.1. Поддерживаемые дистрибутивы Linux

Выпуски YP тестируются со стабильными дистрибутивами Linux из приведенного ниже списка. YP может работать и с другими дистрибутивами, но проверка для них не проводилась. YP не поддерживает и не включает планов по поддержке находящихся в разработке дистрибутивов по причине их частого изменения. Приветствуются исправления (patch) и сообщения об ошибках при работе с такими дистрибутивами, но следует принимать во внимание, что основные усилия разработчиков направлены на перечисленные ниже платформы

Ubuntu 16.04 (LTS);
Ubuntu 18.04;
Fedora 28;
Fedora 29;
CentOS 7.x;
Debian GNU/Linux 8.x (Jessie);
Debian GNU/Linux 9.x (Stretch);
OpenSUSE 42.3.

Yocto Project не совместим с WSL¹ и сборочный хост не будет работать на системе WSL.

При возникновении проблем воспользуйтесь ссылкой Yocto Project Bugzilla для представления ошибки. Информация о работе с системой сбора ошибок доступна на странице YP Bugzilla wiki и в разделе Submitting a Defect Against the Yocto Project [2].

Команда YP старается сделать выпуски YP полностью совместимыми с официально поддерживаемыми дистрибутивами Linux, однако могут возникать проблемы с некоторыми дистрибутивами.

1.2. Пакеты, требуемые на сборочном хосте

Список пакетов, требуемых на сборочном хосте, может быть обширным для охвата всех сценариев сборки, используемых в YP. В этом разделе рассмотрены зависимости в соответствии с дистрибутивами Linux и функциями.

1.2.1. Ubuntu и Debian

Ниже приведен список пакетов, требуемых на сборочном хосте Ubuntu или Debian.

Пакеты для сборки образов.

$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \
xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
xterm

Пакеты для сборки руководств YP.

$ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto

Если в вашей системе сборки установлен пакет oss4-dev, могут возникнуть проблемы при сборке для QEMU по причине установки в Debian своего файла /usr/include/linux/soundcard.h. В таких случаях можно воспользоваться одним из 2 показанных ниже решений.

1.2.2. Fedora

Ниже приведен список пакетов, требуемых на сборочном хосте Fedora Linux.

Пакеты для сборки образов.

$ sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
python3-pexpect findutils which file cpio python python3-pip xz python3-GitPython \
python3-jinja2 SDL-devel xterm

Пакеты для сборки руководств YP.

$ sudo dnf install docbook-style-dsssl docbook-style-xsl \
docbook-dtds docbook-utils fop libxslt dblatex xmlto

1.2.3. OpenSUSE

Ниже приведен список пакетов, требуемых на сборочном хосте openSUSE.

Пакеты для сборки образов.

$ sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \
diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
$ sudo pip3 install GitPython libSDL-devel xterm

Пакеты для сборки руководств YP.
```
     $ sudo zypper install dblatex xmlto
```

1.2.4. CentOS

Ниже приведен список пакетов, требуемых на сборочном хосте CentOS Linux.

Пакеты для сборки образов.
```
     $ sudo yum install -y epel-release
     $ sudo yum makecache
     $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \
     perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python34-pip xz \
     which SDL-devel xterm
     $ sudo pip3 install GitPython jinja2    
```
- Дополнительные пакеты для Enterprise Linux (т. е. epel-release) представляют собой набор программ из Fedora на RHEL/CentOS для простой установки пакетов, не включаемых в корпоративный дистрибутив Linux по умолчанию. Эти пакеты нужно устанавливать отдельно.
- Команда makecache получает дополнительные метаданные от epel-release.

Пакеты для сборки руководств YP.

     $ sudo yum install docbook-style-dsssl docbook-style-xsl \
     docbook-dtds docbook-utils fop libxslt dblatex xmlto

1.3. Требуемые версии Git, tar и Python

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

Git не ниже 1.8.3.1;
tar не ниже 1.27;
Python не ниже 3.4.0.

Если эти требования не выполняются, можно установить пакет buildtools,содержащий эти программы. Пакет можно загрузить в виде архива (tarball) или собрать самостоятельно с помощью BitBake.

1.3.1. Загрузка собранного архива `buildtools`

Загрузка и запуск подготовленного установщика buildtools обеспечивает простейший способ получить инструменты.

По ссылке http://downloads.yoctoproject.org/releases/yocto/yocto-2.7.1/buildtools/ найдите и загрузите файл *.sh.
Запустите сценарий установки, как показано ниже.
```
     $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-2.7.1.sh
```
В процессе работы сценария будут выводиться приглашения для выбора каталога установки. Можно выбрать, например, каталог /home/your-username/buildtools.
Запустите сценарий настройки среды с помощью команды
```
$ source /home/your_username/buildtools/environment-setup-i586-poky-linux
```
Здесь вам нужно будет указать реальный каталог установки и убедиться в использовании подходящего файла (например, i586 или x86-64).

После завершения сценария установки будет добавлен каталог инструментов в переменную PATH и инициализированы другие переменные окружения, нужные для работы с инструментами. В результате вы получите пригодные для работы версии Git, tar, Python и chrpath.

1.3.2. Сборка `buildtools`

Сборка и запуск своего установщика buildtools применяется лишь на сборочных хостах, где уже имеется BitBake. В этом случае сборочный хост служит для создания файла .sh и последующего выполнения этапов для его переноса и запуска на машине, не соответствующей требованиям к Git, tar и Python.

На машине с BitBake нужно организовать среду сборки с помощью установочного сценария (oe-init-build-env).
Для сборки инструментов используется команда BitBake
```
     $ bitbake buildtools-tarball
```
Переменная SDKMACHINE в файле local.conf определяет сборку для 32- или 64-битовой системы.

По завершении сборки файл .sh для установки инструментов размещается в каталоге tmp/deploy/sdk каталога сборки. В имени файла присутствует строка buildtools.
Файл .sh file следует перенести на машину, где не выполняются требования к Git, tar или Python.
На этой машине запускается сценарий .sh для установки программ. Например,
```
     $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-2.7.1.sh
```
В процессе работы сценария выводится приглашение указать каталог для установки. Например, /home/your_username/buildtools.
Запускается сценарий установки параметров окружения
```
$ source /home/your_username/buildtools/environment-setup-i586-poky-linux
```
Здесь вам нужно будет указать реальный каталог установки и убедиться в использовании подходящего файла (например, i586 или x86-64).

После завершения сценария установки будет добавлен каталог инструментов в переменную PATH и инициализированы другие переменные окружения, нужные для работы с инструментами. В результате вы получите пригодные для работы версии Git, tar, Python и chrpath.

Глава 2. Терминология YP

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

Append Files – файлы дополнения

Файлы, добавляющие данный сборки в конец файла задания. Эти файлы называют файлами дополнения BitBake и файлами .bbappend. Система сборки OE предполагает, что для каждого файла дополнения имеется соответствующий файл задания (.bb) – эти файлы должны иметь имена, которые отличают только расширением (например, formfactor_0.0.bb и formfactor_0.0.bbappend).

Информация в файлах дополнения расширяет или переопределяет данные из файла задания с идентичным именем. Пример использования файлов дополнения приведен в разделе Using .bbappend Files in Your Layer [2].

В именах файлов добавления можно использовать шаблон % для сопоставления с именами заданий. Предположим, что файл добавления назван busybox_1.21.%.bbappend. Этот файл будет соответствовать любой версии файла задания busybox_1.21.x.bb, например

     busybox_1.21.1.bb
     busybox_1.21.2.bb
     busybox_1.21.3.bb

Использование символа % допускается лишь непосредственно перед расширением .bbappend.

BitBake

Процессор задач и планировщик, используемый системой сборки OE для создания образов (см. [4]).

Board Support Package (BSP) – пакет поддержки платы

Набор драйверов, определений и других компонент для поддержки конкретной аппаратной конфигурации [6].

Build Directory – каталог сборки

Область, используемая системой OE для сборки кода. Область создается при запуске сценария организации рабочего окружения из каталога исходных кодов (oe-init-build-env). Переменная TOPDIR указывает каталог сборки.

При создании Build Directory обеспечивается достаточная гибкость. Ниже приведены несколько примеров создания каталога сборки, в которых предполагается каталог исходных кодов poky.

Build Directory внутри Source Directory с принятым по умолчанию именем build
```
     $ cd $HOME/poky
     $ source oe-init-build-env    
```
Создание Build Directory в домашнем каталоге с именем test-builds
```
     $ cd $HOME
     $ source poky/oe-init-build-env test-builds    
```
Указание пути к каталогу и имени Build Directory. При этом должны существовать все промежуточные каталоги пути к Build Directory. Ниже показано создание каталога сборки YP-21.0.0 в имеющемся каталоге mybuilds внутри домашнего каталога

$cd $HOME
$ source $HOME/poky/oe-init-build-env $HOME/mybuilds/YP-21.0.0

По умолчанию каталог сборки включает подкаталог TMPDIR, используемый для временных файлов в процессе работы. Каталог TMPDIR не может размещаться в файловой системе NFS2, поэтому каталог сборки по умолчанию не может размещаться на NFS. Однако если требуется разметить его в сети, это можно сделать, установив для переменной TMPDIR каталог локального диска в конфигурационном файле local.conf. В результате это разделяет каталоги TMPDIR и TOPDIR, которым является каталог сборки.

Build Host – сборочный хост

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

Classes – классы

Файлы, обеспечивающие логическую инкапсуляцию и наследование, для упрощения многократного использования шаблонов общего назначения (Глава 6. Классы). Файлы классов используют расширение имен .bbclass.

Configuration File – файл конфигурации

Файлы с глобальными определениями переменных, пользовательскими переменными и данными аппаратной конфигурации. Эти файлы указывают системе OE, что нужно собрать и что включить в образ для поддержки конкретной платформы. Конфигурационный файлы используют расширение .conf. Файл conf/local.conf в каталоге сборки содержит заданные пользователем переменные, которые влияют на каждую сборку. Файл meta-poky/conf/distro/poky.conf определяет переменные конфигурации Yocto distro, используемые только при сборке с этим правилом. Файлы конфигурации машин в дереве исходных кодов определяют переменные для конкретного оборудования и используются лишь при сборке для соответствующей цели (например, файл machine/beaglebone.conf используется при сборке для плат Texas Instruments ARM Cortex-A8).

Container Layer – контейнерный уровень

Уровень, содержащий другие уровни. Примером контейнерного уровня является OE meta-openembedded, содержащий множество уровней meta-*.

Cross-Development Toolchain – инструменты кросс-разработки

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

YP поддерживает два набора инструментов для кросс-разработки:

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

Создание этого инструментария достаточно просто и автоматизировано. Информация о концепциях работы инструментария приведена в разделе Cross-Development Toolchain Generation [1], а также в документе [7].

Extensible Software Development Kit (eSDK) – расширяемый пакет для разработки программ

Специализированный пакет SDK3 для разработки приложений, позволяющий разработчикам встраивать свои библиотеки и изменения программ в образ, а также делать свой код доступным для других разработчиков [7].

Image – образ

Образ является конечным результатом процесса сборки BitBake для заданного набора заданий и связанных с ними метаданных. Образы являются двоичным выводом, предназначенным для работы на конкретном оборудовании или QEMU и применяемым для определенных задач. Список поддерживаемых YP типов образов представлен ниже (Глава 11. Образы).

Layer – уровень

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

Базовые сведения об уровнях приведены в разделе The Yocto Project Layer Model [1], а более подробная информация – в разделе Understanding and Creating Layers [2]. Уровни BSP рассмотрены в разделе BSP Layers [6].

Metadata – метаданные

Используются для создания дистрибутивов Linux и содержатся в файлах, которые система сборки OE анализирует при сборке образа. В общем случае метаданные включают задания, конфигурационные файлы и другую информацию, относящуюся к инструкциям по сборке, а также данные, управляющие тем, что создается, и влияющие на сборку. Метаданные включают команды и данные, используемые для указания используемых версий программ, места, откуда их следует загружать, и изменениях или дополнениях к этим программам (исправления или дополнительные файлы) для исправления ошибок или настройки под конкретную задачу. OpenEmbedded-Core содержит важный для работы набор проверенных метаданных.

В контексте ядра (kernel Metadata) термин относится к фрагментам конфигурации ядра и функциям, включенным в репозиторий yocto-kernel-cache Git.

OpenEmbedded-Core (OE-Core)

OE-Core – это метаданные, включающие основные задания, классы и связанные с ними файлы, которые должны быть общими для множества разных систем, производных от OE, включая YP. OE-Core представляет собой подмножество репозитория, созданного сообществом OE, которое было собрано в меньших набор проверенных заданий. Результатом стал строго контролируемый и качественный набор базовых заданий.

Эти метаданные можно просмотреть в каталоге meta Yocto Project Source Repositories.

OpenEmbedded Build System – система сборки OpenEmbedded

Система сборки в составе YP, основанная на проекте Poky, использующем BitBake для выполнения задач. В документации YP система сборки OE иногда называется просто системой сборки. При указании других систем сборки (например, на хосте или целевой платформе) они задаются явно.

Package – пакет

В контексте YP пакетом называется результат выполнения задания, созданный BitBake (выполненное задание), – обычные двоичные файлы, созданные из исходных кодов задания.

С использованием термина «пакет» связаны некоторые нюансы. Например, пакеты, упоминаемые в параграфе 1.2. Пакеты, требуемые на сборочном хосте, являются скомпилированными двоичными файлами, установка которых расширяет функциональность вашего дистрибутива Linux. Исторически в рамках YP пакетами назывались задания и некоторые переменные BitBake в результате сохранили не вполне корректные имена (например PR, PV, PE).

Package Groups – группа пакетов

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

Poky

Poky (произносится Pock-ee) является эталонным дистрибутивом для встраиваемых систем и тестирования. Возможности Poky приведены ниже.

Базовый дистрибутив для иллюстрации настройки своего дистрибутива.
Средства и способы тестирования компонент YP (т. е. Poky служит для проверки YP).
Средство для загрузки YP.

Poky не является дистрибутивом для реального применения, это просто стартовая точка для создания дистрибутива. Проект poky начинался с открытой системы, разработанной OpenedHand на основе имевшейся системы сборки OE для создания коммерчески поддерживаемой системы сборки Linux для встраиваемых систем. После покупки OpenedHand корпорацией Intel проект poky стал основой для системы сборки YP.

Recipe – задание

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

Reference Kit – эталонный комплект

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

Source Directory – каталог исходных кодов

Этот термин обозначает структуру (дерево) каталогов, созданную как локальная копия репозитория poky Git git://git.yoctoproject.org/pokyили распакованную из архива poky. Создание локальной копии репозитория poky Git рекомендуется в качестве метода организации Source Directory. Иногда для структуры используется название «каталог poky».

Система OE не поддерживает имена каталогов и файлов, содержащие пробелы, поэтому следует убедиться в их отсутствии в имени Source Directory.

Структура Source Directory содержит BitBake, документацию, метаданные и другие файлы, нужные для YP. Следовательно, Source Directory является необходимой частью YP.

При создании локальной копии репозитория Git ему можно дать любое имя. В документации обычно используется poky в качестве имени каталога верхнего уровня для локальной копии репозитория poky Git. Обычное клонирование репозитория poky Git без указания локального имени будет создавать копию в каталоге poky.

Если вы будете создавать Source Directory из архива, имя каталога верхнего уровня также будет взято из этого архива. Например, при загрузке и распаковке архива poky-warrior-21.0.0.tar.bz2 вы получите Source Directory с корневым каталогом poky-warrior-21.0.0.

Важно понимать различия между Source Directory из архива и путем клонирования git://git.yoctoproject.org/poky. При распаковке архива вы получите копии файлов конкретного выпуска и внесенные вами изменения будут сохраняться лишь локально. При работе с локальным репозиторием poky Git вы будете иметь свежие копии файлов, а внесенные изменения можно будет представить в находящиеся в разработке ветви репозитория poky Git.

Дополнительную информацию о работе с репозиториями Git, ветвями и тегами можно найти в разделе Repositories, Tags, and Branches [1].

Task – задача

Блок выполнения в BitBake (например, do_compile, do_fetch, do_patch и т. п.).

Toaster

Web интерфейс для системы сборки OpenEmbedded, позволяющий настраивать и запускать сборку. Информация о сборке собирается и храниться в базе данных [8].

Upstream

Ссылка на исходный код или репозитории, которые не находятся в системе разработки, а расположены в области, поддерживаемой разработчиками (maintainer) исходного кода. Например, для работы с определенной частью кода его нужно сначала получить из «восходящего» источника.

Глава 3. Выпуски YP и создание стабильного выпуска

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

3.1. Основные и второстепенные выпуски

Основные выпуски YP (например, 2.7.1) выходят с интервалом около 6 месяцев в апреле и октябре каждого года. Ниже приведены несколько основных выпусков YP с кодовыми именами (см. 3.2. Кодовые имена основных выпусков).

2.2 (Morty);

2.1 (Krogoth);

2.0 (Jethro).

Временные интервалы никогда не бывают точными, но полугодовой интервал облегчает регулярные выпуски с жестким контролем качества (QA⁴) без перегрузки пользователей частой сменой выпусков. Месяцы выпуска выбраны с учетом продолжительных праздников в разных странах.

Второстепенные выпуски YP (младшая цифра) выходят нерегулярно и обычно вызваны накоплением достаточно важных изменений или улучшений последнего основного выпуска. Ниже приведены примеры второстепенных выпусков.

2.1.1;

2.1.2;

2.2.1.

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

Могут также выпускаться исправления (patch) к стабильному выпуску по мере их появления.

3.2. Кодовые имена основных выпусков

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

Кодовое имя связывается с основным выпуском, поскольку номер выпуска YP (например, 2.7.1) может конфликтовать с данным уровнем или схемой нумерации версий компании. Кодовые имена уникальны и легко узнаваемы.

Выпуски тоже имеют номинальную версию и по этой причине в репозиториях используется кодовое имя. Информацию о выпусках и кодовых именах YP можно найти по ссылке https://wiki.yoctoproject.org/wiki/Releases.

3.3. Процесс подготовки стабильного выпуска

После выхода нового стабильного выпуска назначается ответственный за его поддержку. Этот человек отслеживает связанные с выпуском события, исследуя и обрабатывая предложенные изменения. Для передачи в стабильный выпуск рассматриваются только исправления и улучшения в ветви master (текущая разрабатываемая ветвь).

Текущая политика YP в части переноса в стабильные выпуски принимает во внимание лишь исправления ошибок и связанные с безопасностью изменения. Это означает, что обновления версии базового задания вряд ли будут приняты для стабильных выпусков. Исключением может служить наличие веских причин, таких как исправления, которые имеет смысл принять и в разрабатываемой версии.

Стабильные выпуски сопровождаются в течение года с момента публикации. Если будут обнаружены серьезные проблемы, исправления будут перенесены в прошлые выпуски независимо от их возраста. Для проблем, решения которых не были перенесены в прошлые выпуски, имеются деревья и ветви Community LTS, где участники делятся patch-файлами для прошлых выпусков. Однако эти исправления не проходят строгого контроля. Информацию о поддержке стабильных ветвей можно найти по ссылке https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance.

3.4. Тестирование и контроль качества

Частью процесса разработки и выпуска YP является контроль качества, основанный на тестировании. Стратегия тестирования позволяет команде YP проверить готовность выпуска. Кроме того, стратегия тестирования доступна для разработчиков, что позволяет вам проверить свои проекты. В этом разделе приведен обзор инфраструктуры тестирования YP. Дополнительную информацию о доступных тестах для ваших проектов можно найти в разделе Performing Automated Runtime Testing [2].

Инфраструктура тестирования и контроля качества интегрирована в проект и включает несколько частей.

bitbake-selftest – автономная команда для запуска тестирования основных частей BitBake и его сборщиков.
sanity.bbclass – автоматически включаемый класс для проверки полноты инструментов среды сборки и ошибок в базовой конфигурации (например, некорректная установка переменной MACHINE).
insane.bbclass – проверка вывода сборки на здравомыслие. Например, при сборке для платформы ARM проверяется назначение выходных двоичных файлов именно для этой платформы.
testimage.bbclass – тестирование работы созданных при сборке образов. Тесты обычно применяются с QEMU для загрузки образа и проверки его работы. Однако тест может также выполняться для машины, указанной адресом IP.
ptest запускает тесты для пакетов, созданных при сборке программ. Тесты выполняются на целевом образе.
oe-selftest тестирует вызовы BitBake. Эти тесты выполняются вне системы сборки OE. Команда oe-selftest по умолчанию запускает все тесты, но можно указать набор нужных тестов. Для использования oe-selftest на хосте нужно установить дополнительные пакеты (см. параграф 1.2. Пакеты, требуемые на сборочном хосте).

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

Основной автосборщик YP (autobuilder.yoctoproject.org) тестирует код каждого выпуска YP из репозиториев OE-Core, Poky и BitBake. Тестирование выполняется для текущего состояния ветви master и предложенных исправлений. Для исправлений тестирование обычно проходит в ветви ross/mut репозитория poky-contrib (ветвь master-under-test) или master-next в репозитории poky.

Тестирование этих общедоступных ветвей обеспечивает для всех желающих информацию о проверке предложенных вариантов архитектуры и заданий OE-Core. В тестах QA проверяются разные свойства, такие как multilib, субархитектура (например, x32, poky-tiny, musl, no-x11), bitbake-selftest, oe-selftest. Полное тестирование и проверка выпуска в Autobuilder занимает несколько часов. Тестирование выполняется в разных дистрибутивах Linux на системах QEMU, а не на реальном оборудовании. В дополнение к тестам Autobuilder команда YP QA выполняет тесты на разных платформах.

Глава 4. Переход на новые выпуски YP

В этой главе представлена информация о переходе с одного выпуска YP на другой. Дополнительные сведения можно получить из заметок (release notes) к соответствующему выпуску.

4.1. Общие вопросы

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

Работа с пользовательскими заданиями

Могут возникать проблемы при использовании заданий, которые были изменены в прежнем выпуске и просто скопированы в новый. Например, задание на вашем уровне может содержать измененное задание core из прежнего выпуска, а не использовать файл добавления. При переходе на новый выпуск YP метаданные (например, включенные в задание файлы) могут измениться так, что ваше задание не будет работать. Это может быть, например, следствием удаления из включенного файла функции, которую задание пытается использовать.

Вы может скорректировать все настройки в своем задании для работы с новым выпуском, однако это решение не будет оптимальным, поскольку процесс придется повторять для каждого нового выпуска, если проблемы будут возникать. Более эффективным решением будет использование файлов добавления (*.bbappend) для фиксации ваших настроек задания. Это изолирует внесенные вами изменений от основного задания и сделает процесс более контролируемым. Однако на практике использование файлов добавления удобно не всегда. Вариантом решения проблемы может быть создание нового задания или перенос прежнего на другой уровень.

Обновление файлов дополнения (Append)

Поскольку файлы добавления обычно содержат лишь пользовательские настройки, из часто не нужно настраивать для новых выпусков. Однако, если файл .bbappend относится к конкретной версии задания (т. е. в имени не используется шаблон %) и версия задания будет изменена, потребуется по меньшей мере переименовать файл добавления в соответствии с новым файлом задания. Несоответствие имени файла дополнения и задания (.bb) приведет к ошибке при анализе.

В зависимости от типа настроек в файле добавления при обновлении выпуска могут возникать и другие несовместимости. Например, если файл добавления применяет исправления, а дополненное им задание обновлено до новой версии, patch-файла может не оказаться. В таких случаях нужно обновить patch-файл, если необходимость его сохраняется.

4.2. Переход на YP 1.3

В этом разделе рассмотрен переход на YP 1.3 с предыдущего выпуска.

4.2.1. Локальная конфигурация

Изменена переменная SSTATE_MIRRORS и файл bblayers.conf.

4.2.1.1. SSTATE_MIRRORS

Кэш общих состояний (sstate-cache), указанный переменной SSTATE_DIR, по умолчанию использует двухсимвольные имена каталогов для предотвращения проблем, связанных с чрезмерным числом файлов в одном каталоге. Кроме того, естественные пакеты sstate-cache, которые собираются для работы на сборочном хосте, будут помещаться в подкаталог, имя которого содержит идентификатор дистрибутива. Если вы копируете недавно структурированные данные sstate-cache на зеркало (локальное или удаленное), и указываете его в переменной SSTATE_MIRRORS, нужно добавлять в конце URL зеркала строку PATH, используемую BitBake перед добавлением пути к зеркалу. Например,

SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"

4.2.1.2. bblayers.conf

Уровень meta-yocto состоит из 2 частей, соответствующих дистрибутиву Poky и пакетам поддержки плат BSP⁵ – meta-yocto и meta-yocto-bsp,соответственно. При первом запуске BitBake после обновления файл conf/bblayers.conf будет обновлен с учетом этих изменений и будет выведено предложение о перезапуске для учета изменений.

4.2.2. Задания

Изменения в заданиях включают:

пробелы в функциях Python;
proto= в SRC_URI;
nativesdk;
задания для задач;
IMAGE_FEATURES;
удаленные задания.

4.2.2.1. Пробелы в функциях Python

Все функции Python должны использовать отступы из 4 пробелов. Ранее допускалось произвольное смешивание пробелов и символов табуляции, что усложняло расширение этих функций с помощью _append или _prepend с учетом того, что Python считает пробелы синтаксически значимыми. При определении или расширении функций Python (например, populate_packages, do_unpack, do_patch) в пользовательских заданиях или классах нужно использовать отступы из 4 пробелов.

4.2.2.2. proto= в SRC_URI

Все включения proto= в SRC_URI должны быть заменены на protocol=. Это относится к URI типов svn://, bzr://, hg:// и osc://, поскольку
в остальных уже используется protocol=.

4.2.2.3. nativesdk

Суффикс nativesdk сейчас реализован в виде префикса что значительно упрощает упаковочный код для заданий nativesdk. Все пользовательские задания nativesdk, которые являются перемещаемыми пакетами и естественны для SDK_ARCH, а также все ссылки нужно обновить с использованием nativesdk-* вместо *-nativesdk.

4.2.2.4. Задания для задач

Задания для задач сейчас называются группами пакетов (Package group) и переименованы – вместо task-*.bb используется packagegroup-*.bb. Имеющиеся ссылки на имена прежних задач task-* будут в большинстве случаев работать, поскольку для большинства пакетов существует путь автоматического обновления. Однако нужно будет обновить ссылки в ваших заданиях и конфигурациях, поскольку в будущих выпусках они могут уже не работать. Следует переименовать пользовательские задания task-* в to packagegroup-* и изменить их для наследования packagegroup вместо task, а также удалить все, что обрабатывалось классом packagegroup.bbclass (например, предоставление пакетов -dev и -dbg, установка переменной LIC_FILES_CHKSUM и т. п.). Дополнительная информация приведена в параграфе 6.94. packagegroup.bbclass.

4.2.2.5. IMAGE_FEATURES

Заданиям для образов, включавшим apps-console-core в переменной IMAGE_FEATURES, следует вместо этого указывать splash для включения заставки при загрузке. При сохранении apps-console-core заставка будет включаться, но с выдачей предупреждения. Свойства apps-x11-core и apps-x11-games для IMAGE_FEATURES были удалены.

4.2.2.6. Удаленные задания

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

libx11-trim заменено на libx11, практически не отличающийся по размеру от современного Xorg.
xserver-xorg-lite – используйте взамен xserver-xorg, который практически не отличается по размеру, когда модули DRI и GLX не установлены.
xserver-kdrive – уже много лет не поддерживался.
mesa-xlib - больше не нужно.
galago – заменено на telepathy.
gail – функционально интегрировано в GTK+ 2.13.
eggdbus – больше не нужно.
gcc-*-intermediate – сборка реструктурирована для исключения этого этапа.
libgsmd – уже много лет не поддерживался. Функциональной заменой служит ofono.
contacts, dates, tasks, eds-tools – практически не поддерживаемый набор приложений PIM. Перемещено в meta-gnome уровня meta-openembedded.

В дополнение к перечисленным изменениям, каталог meta-demoapps был удален, поскольку содержащиеся в нем задания не поддерживались и многие из них устарели или были запрошены. Кроме того, эти задания не анализировались в принятой по умолчанию конфигурации. Многие из этих заданий уже заменены и поддерживаются в уровнях сообщества OE, таких как meta-oe и meta-gnome. Остальные можно найти в репозитории meta-extras на YP.

4.2.3. Именование ядер Linux

Схема именования двоичных файлов ядра изменена с включением переменной PE как части имени KERNEL_IMAGE_BASE_NAME ?= “${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}”. Поскольку переменная PE по умолчанию не задана, двоичные файлы по умолчанию будут включать в имени два символа дефиса (–). Например, bzImage–3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin

4.3. Переход на YP 1.4

В этом разделе рассмотрен переход на YP 1.4 с предыдущего выпуска.

4.3.1. BitBake

Многострочные комментарии. Если строка комментария завершается символом \, следующая строка также будет являться комментарием. Все нарушения этого правила будут приводить к выводу предупреждений. В текст файлов с такими нарушения следует внести соответствующие правки.
Переопределение имен пакетов. Переменным, относящимся к именам пакетов во время выполнения (RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RCONFLICTS, RREPLACES, FILES, ALLOW_EMPTY), а также функциям сценариев, связанных с установкой (pkg_preinst, pkg_postinst, pkg_prerm, pkg_postrm), всегда следует переопределять имена пакетов. Например, для основного пакета следует использовать RDEPENDS_${PN},а не простоRDEPENDS. BitBake использует более строгую проверку при анализе заданий.

4.3.2. Поведение при сборке

Код общего состояния был оптимизирован для предотвращения работы ненужных задач. Например, приведенная ниже команда больше не заполняет sysroot, поскольку это не требуется.
```
$ bitbake -c rootfs some-image
```
Вместо этого системе нужно просто извлечь содержимое выходных пакетов, заново создать пакеты и организовать корневую файловую систему. Это изменение не вызовет каких-либо проблем, если соблюдены объявленные зависимости.
Имена сканируемых каталогов. При сканировании для поиска файлов из SRC_URI система сборки использует для имен каталогов переменную FILESOVERRIDES вместо OVERRIDES. Обычно значение OVERRIDES совпадают с FILESOVERRIDES, однако при использовании дополнительного значения в OVERRIDES может потребоваться его добавление в FILESOVERRIDES, если оно уже не добавлено в переменную MACHINEOVERRIDES или DISTROOVERRIDES (Глава 13. Переменные).

4.3.3. Прокси и извлечение исходного кода

Добавлен сценарий oe-git-proxy для извлечения источников из репозиториев Git через прокси. Работа со сценарием описана в файле meta-yocto/conf/site.conf.sample.

4.3.4. Пользовательские интерфейсные файлы (изменение netbase)

Если вы создали свой файл etc/network/interfaces с помощью добавления к заданию netbase, вместо него потребуется создать файл добавления к заданию init-ifupdown, которое можно найти в каталоге meta/recipes-core/init-ifupdown дерева исходных кодов (см. раздел Using .bbappend Files [2]).

4.3.5. Удаленная отладка

Поддержка удаленной отладки с использованием Eclipse IDE выделена в свойство образа (eclipse-debug), которое соответствует группе пакетов packagegroup-core-eclipse-debug. Ранее отладка включалась через свойство tools-debug из группы packagegroup-core-tools-debug.

4.3.6. Переменные

SANITY_TESTED_DISTROS использует идентификатор дистрибутива, состоящий из идентификатора хоста, за которым следует идентификатор выпуска. Ранее переменная SANITY_TESTED_DISTROS содержала поле описания. Например, значение Ubuntu 12.10 становится Ubuntu-12.10. Это изменение не затронет вас, если переменная не задавалась или содержала пустое значение (“”).
SRC_URI. Каталоги ${PN}, ${PF}, ${P} и FILE_DIRNAME исключены из принятого по умолчанию значения переменной FILESPATH, которая служит для указания пути поиска файлов, заданных в SRC_URI. Если ваши задания используют указанные каталоги нужно внести изменения в задание или переместить файлы. Часто используемые каталоги включены в переменные ${BP}, ${BPN} и files, которые сохранены в принятом по умолчанию значении FILESPATH.

4.3.7. Управление пакетами целевой платформы с помощью RPM

Управление пакетами в процессе работы разрешено и используется механизм RPM. Вместо Zypper устанавливается пакет Smart для загрузки программ, контроля зависимостей и обновления. Информация о работе со Smart выводится по команде smart –help.

4.3.8. Перенос заданий

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

clutter-box2d на уровень meta-oe.
evolution-data-server на уровень meta-gnome.
gthumb на уровень meta-gnome.
gtkhtml2 на уровень meta-oe.
gupnp на уровень meta-multimedia.
gypsy на уровень meta-oe.
libcanberra на уровень meta-gnome.
libgdata на уровень meta-gnome.
libmusicbrainz на уровень meta-multimedia.
metacity на уровень meta-gnome.
polkit на уровень meta-oe.
zeroconf на уровень meta-networking.

4.3.9. Удаления и переименования

evieext удалено по причине удаления из xserver в 2008 г.
Gtk+ DirectFB удалено по причине исключения из Gtk+ начиная с версии 2.18.
libxfontcache, xfontcacheproto удалены по причине удаления из сервера Xorg в 2008 г.
libxp, libxprintapputil, libxprintutil, printproto удалены по причине удаления сервера XPrint из Xorg в 2008 г.
libxtrap, xtrapproto удалены по причине отказа от этой функциональности.
Ядро linux-yocto 3.0 заменено ядром linux-yocto 3.8, ядра linux-yocto 3.2 и linux-yocto 3.4 сохранены в выпуске.
lsbsetup удалено, поскольку функциональность обеспечивается lsbtest.
matchbox-stroke удалено, поскольку служило лишь для проверки концепции.
matchbox-wm-2, matchbox-theme-sato-2 удалены, поскольку больше не поддерживаются. Однако matchbox-wm и matchbox-theme-sato сохранены.
mesa-dri переименовано в mesa.
mesa-xlib удалено по причине бесполезности.
mutter удалено по причине ненужности.
orinoco-conf удалено, поскольку устарело.
update-modules удалено, поскольку больше не применяется. Сценарии postinstall и postrm для модулей ядра работают без этого сценария.
web удалено, поскольку больше не поддерживаются и заменено на web-webkit.
xf86bigfontproto удалено по причине исключения из разработки в 2007 г. Сейчас применяется xf86bigfontproto.
xf86rushproto удалено, поскольку зависимость от xserver была ошибочной и удалена в 2005 г.
zypper, libzypp, sat-solver удалены и функционально заменены на Smart (python-smartpm) при использовании пакетов RPM и включенном на целевой платформе менеджере пакетов.

4.4. Переход на YP 1.5

В этом разделе рассмотрен переход на YP 1.5 с предыдущего выпуска.

4.4.1. Изменения зависимостей для сборочного хоста

Система сборки OE предъявляет приведенные ниже требования к программам сборочного хоста.

Python 2.7.3 или выше;
Tar 1.24 или выше;
Git 1.7.8 или выше;
исправленная версия make при использовании 3.82 (применяется в большинстве дистрибутивов с make 3.82).

Если в дистрибутиве Linux на сборочном хосте нет указанных версий программ, можно воспользоваться архивом Buildtools, включающим эти программы (см. параграф 1.3. Требуемые версии Git, tar и Python).

4.4.2. `atom-pc` BSP

Эталонный аппаратный пакет BSP для atom-pc заменен BSP genericx86. Он не обязательно будет работать на всех системах x86, но пригоден для работы на большинстве систем, где работал atom-pc. Кроме того, добавлен BSP genericx86-64 для 64-битовых систем Atom.

4.4.3. BitBake

BitBake теперь поддерживает оператор _remove, что потребует переименовать все элементы (функции, переменные) в пространстве задания, содержащие _remove_ или заканчивающиеся _remove, для предотвращения неожиданного поведения.
Удален глобальный (global) метод извлечения (pool) для BitBake, который был практически бесполезен и приводил к конфликтам с заданиями, содержащими функции с таким же именем.
Удален backend-сервер none, поскольку по умолчанию уже давно применяется сервер process.
Удален сценарий bitbake-runtask.
Переменные ${P} и ${PF} больше не добавляются по умолчанию в переменную PROVIDES файла bitbake.conf. Эти зависимые от версии элементы PROVIDES применялись редко и попытка использовать их может приводить к одновременной сборке двух версий в результате используемого в BitBake метода контроля зависимостей.

4.4.4. Предупреждения QA

При установке значений ERROR_QA или WARN_QA в вашей конфигурации следует убедиться, что там указаны все проблемы, которые вы хотите видеть. В предыдущих выпусках YP была ошибка, в результате которой объекты, не указанные в ERROR_QA или WARN_QA, считались предупреждениями и некоторые важные элементы не включались по умолчанию в WARN_QA. Проверки QA описаны в параграфе 6.56. insane.bbclass.
Добавлена проверка установки /usr/share/info/dir. В вашем задании следует удалить этот файл в задаче do_install, если его устанавливает команда make install.
При использовании класса buildhistory проверка возврата версии пакетов выполняется стандартной процедурой QA. Если вы изменили значение ERROR_QA или WARN_QA и по-прежнему хотите выполнять эту проверку, следует добавить значение version-going-backwards переменной (см. параграф 6.56. insane.bbclass).

4.4.5. Изменение схемы каталогов

Выходные файлы установщика SDK имеют имена, включающие имя образа и архитектуру через переменную SDK_NAME.
Образы и связанные с ними файлы устанавливаются в каталог, определяемый машиной, а не в родительский каталог с выходными файлами для разных машин. Переменная DEPLOY_DIR_IMAGE по-прежнему указывает каталог с образами для конкретного значения MACHINE и ее следует применять везде, где нужно указывать этот каталог. Сценарий runqemu теперь использует эту переменную для поиска образов и двоичных файлов ядра и будет применять BitBake для определения каталога. Дополнительно можно установить переменную DEPLOY_DIR_IMAGE во внешней среде.
При включенном классе buildhistory его вывод будет записываться в каталог сборки, а не в TMPDIR. Это позволяет удалить TMPDIR с сохранением истории. Кроме того, данные для создаваемых SDK разделены по IMAGE_NAME.
Данные pkgdata, создаваемые в процессе упаковки, сжаты до одного каталога, определяемого машиной. Этот каталог размещается в sysroots и использует определяемое машиной имя (tmp/sysroots/machine/pkgdata).

4.4.6. Сокращенные значения Git `SRCREV`

BitBake сокращает выпуски из репозиториев Git в переменной SRCPV с обычных 40 до 10 для удобочитаемости в именах файлов и каталогов. Это изменение не должно создавать проблем в контексте, где применяются эти выпуски, поскольку вероятность конфликтов очень мала. Совпадение значений в разном контексте проблем не вызывает.

4.4.7. `IMAGE_FEATURES`

Значение IMAGE_FEATURES сейчас проверяется, чтобы предотвратить добавление непригодных элементов. Некоторые пользователи ошибочно добавляют имена пакетов в эту переменную вместо использования IMAGE_INSTALL для добавления пакетов в образ. Пригодное значение IMAGE_FEATURES выводится из определений PACKAGE_GROUP, COMPLEMENTARY_GLOB и нового флага validitems в IMAGE_FEATURES. Изменение validitems позволяет добавить свойства если они не включены двумя предыдущими механизмами.
Ранее отмененный элемент IMAGE_FEATURES apps-console-core больше не поддерживается. Если нужно включить экран заставки, добавьте splash в переменную IMAGE_FEATURES(это все, что делал элементapps-console-core).

4.4.8. `/run`

Был добавлен каталог /run в соответствии с Filesystem Hierarchy Standard 3.0. Последствия этого описаны на сайте. Изменение также привело к изменению заданий, устанавливающих файлы в каталог (рекомендации по внесению изменений доступны по ссылке.

4.4.9. Удаление базы данных менеджера пакетов из заданий для образов

Образcore-image-minimal больше не добавляет remove_packaging_data_files в переменную ROOTFS_POSTPROCESS_COMMAND. Это добавление происходит автоматически при отсутствии package-management в IMAGE_FEATURES. Если у вас есть задания с таким добавлением, нужно удалить соответствующие строки, поскольку они больше не нужны и могут создавать проблемы при выполнении пост-установочных сценариев.

4.4.10. Повторная сборка образов только при наличии изменений

Задача do_rootfs и другие задачи, связанные с созданием образов, больше не помечаются как nostamp, поэтому будут выполняться повторно лишь при наличии реальных изменений на их входе. В прежних выпусках система OE всегда заново собирала образ по запросу, е не по необходимости.

4.4.11. Задания для задач

Ранее отмененный класс task.bbclass удален. Для заданий, наследовавших этот класс следует заменить task-* на packagegroup-* и наследовать класс packagegroup.

4.4.12. BusyBox

Пакет BusyBox разделен на два двоичных исполняемых файла, один из которых использует для тех компонент, где это требуется, а второй служит для остальных задач. Такое разделение сделало возможной оптимизацию, которая исключает задание tinylogin, как было рекомендовано разработчиками. Расщепление можно отключить, установив значение 0 для переменной BUSYBOX_SPLIT_SUID.

4.4.13. Автоматизированное тестирование образов

Добавлена новая модель автоматизированного тестирования образа с использованием класса testimage.bbclass взамен старой схемы imagetest-qemu. Автоматизированное тестирование образов рассмотрено в разделе Performing Automated Runtime Testing [2].

4.4.14. История сборки

В файле installed-package-sizes.txt сейчас записываются размеры установленных файлов каждого пакета, а не размер сжатого архива.
В графах зависимостей (depends*.dot) используются реальные имена пакетов без замены символов дефиса, точек, знаков + и символов подчеркивания.
В утилитах buildhistory-diff и buildhistory-collect-srcrevs улучшена обработка параметров командной строки, которые можно посмотреть с помощью опции –help.

Работа с историей сборок описана в разделе Maintaining Build Output Quality [2].

4.4.15. `udev`

udev больше не приводит автоматически в udev-extraconf через переменную RRECOMMENDS, поскольку это изначально предполагалось необязательным. Если нужны дополнительные правила, используйте udev-extraconf для своего образа.
udev больше не приводит в pciutils-ids или usbutils-ids через переменную RRECOMMENDS. Они не нужны и их удаление экономит около 350 кбайт.

4.4.16. Удаленные и переименованные задания

Удалено ядро linux-yocto 3.2.
libtool-nativesdk переименовано с nativesdk-libtool.
Удалено tinylogin с заменой на suid-часть Busybox (см. параграф 4.4.12. BusyBox).
external-python-tarball переименован в buildtools-tarball.
web-webkit удален с заменой на midori.
imake удалено за ненадобностью.
transfig-native удалено за ненадобностью.
anjuta-remote-run удалено. Интеграция с Anjuta IDE не поддерживается уже несколькими выпусками.

4.4.17. Прочие изменения

run-postinsts является базовым.
Из base-files удалены ненужные каталоги.
alsa-state обеспечивает по умолчанию пустой файл asound.conf.
classes/image гарантирует для BAD_RECOMMENDATIONS заранее переименованных пакетов.
classes/rootfs_rpm реализует BAD_RECOMMENDATIONS для RPM.
systemd – удаляется systemd_unitdir, если systemd нет в DISTRO_FEATURES.
systemd – удаляется каталог init.d, если имеется файл инициализации systemd и sysvinit не является свойством дистрибутива.
libpam отвергает все службы для записей OTHER.
image.bbclass – перемещено runtime_mapping_rename для предотвращения конфликтов с multilib (см. YOCTO #4993 ).
linux-dtb использует систему сборки ядра для генерации файлов dtb.
kern-tools переключен с guilt на новый инструмент kgit-s2q.

4.5. Переход на YP 1.6

В этом разделе рассмотрен переход на YP 1.6 с предыдущего выпуска.

4.5.1. Класс `archiver`

Класс archiver был переписан с упрощением конфигурации. См. раздел Maintaining Open Source License Compliance During Your Product’s Lifecycle [2].

4.5.2. Изменения в пакетах

Задание binutils больше не создает пакет binutils-symlinks и применяется update-alternatives при обработке предпочтительного варианта binutils для целевой платформы.
Утилиты tc (управление трафиком) выделены из пакета iproute2 и помещены в пакет iproute2-tc.
Схемы gtk-engines перенесены в отдельный пакет gtk-engines-schemas.
Изменен суффикс архитектуры для пакетов armv7a,который теперьдля пакетов с оптимизацией имеет значение t2, как и должно быть. Этот суффикс не применялся в выпуске 1.5. Результатом является изменение имен архитектуры для пакетов.

4.5.3. BitBake

В следующих параграфах рассмотрены изменения в BitBake.

4.5.3.1. Требование к соответствию ветвей для сборщика Git

При извлечении исходных кодов из репозитория Git с использованием переменной SRC_URIпрограмма BitBake будет сравнивать значение SRCREV с ветвью. Для указания ветви можно использовать приведенную ниже форму.

SRC_URI = "git://server.name/repository;branch=branchname"

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

Если нужно обойти проверку (например, при извлечении версии по тегу, не относящемуся к ветвям), можно добавить “;nobranch=1” в конце URL в переменной SRC_URI.

4.5.3.2. Подстановки определений Python

BitBake включал некоторые устаревшие определения Python в удаленном модуле bb,вместо которых следует применять указанные ниже аналоги.

bb.MalformedUrlзаменяетсяbb.fetch.MalformedUrl.
bb.encodeurlзаменяетсяbb.fetch.encodeurl.
bb.decodeurlзаменяется bb.fetch.decodeurl
bb.mkdirhierзаменяетсяbb.utils.mkdirhier.
bb.movefileзаменяетсяbb.utils.movefile.
bb.copyfileзаменяетсяbb.utils.copyfile.
bb.whichзаменяетсяbb.utils.which.
bb.vercmp_stringзаменяетсяbb.utils.vercmp_string.
bb.vercmpзаменяетсяbb.utils.vercmp.

4.5.3.3. Сборщик SVK

Сборщик SVK исключен из BitBake.

4.5.3.4. Перенаправление консольного вывода ошибок

Консольный интерфейс BitBake будет направлять ошибки вывода на устройство stderr вместо stdout. Поэтому при использовании конвейеров, перенаправляющих вывод bitbake,и желании видеть ошибки, нужно добавить2>&1 (или что-то похожее) в конце командной строки bitbake.

4.5.3.5. Переопределения `task-taskname`

Переопределенияtask-taskname скорректированы так, что задачи, чьи имена содержат символы подчеркивания были переопределены в заменой этих символов дефисами для обеспечения корректной работы. Например, задача do_populate_sdk переопределена как task-populate-sdk.

4.5.4. Изменения переменных

Ниже указаны измененные переменные. Описаниям переменных системы сборки посвящена Глава 13. Переменные.

4.5.4.1. `TMPDIR`

ПеременнаяTMPDIR больше не может указывать файловые системы NFS, поскольку они не обеспечивают блокировки POSIX и согласованности inode, что может вызывать проблемы. Проверка выполняется при запуски и выводится сообщение об ошибке, если TMPDIR указывает NFS.

4.5.4.2. `PRINC`

Переменная PRINC устарела и будет вызывать предупреждения в процессе сборки. Для инкрементирования при изменениях следует использовать переменную PR. Дополнительная информация приведена в разделе Working With a PR Service [2].

4.5.4.3. `IMAGE_TYPES`

Опция sum.jffs2 для IMAGE_TYPES заменена опцией jffs2.sum, с сохранением порядка обработки.

4.5.4.4. `COPY_LIC_MANIFEST`

Для включения переменной COPY_LIC_MANIFEST теперь используется значение 1.

4.5.4.5. `COPY_LIC_DIRS`

Для включения переменнойCOPY_LIC_DIRS теперь используется значение 1.

4.5.4.6. `PACKAGE_GROUP`

Переменная PACKAGE_GROUP переименована в FEATURE_PACKAGES,чтобы точнее отражать ее назначение. ПеременнуюPACKAGE_GROUP можно использовать, но система сборки OE будет выдавать предупреждения.

4.5.4.7. Поведение команд предварительной и пост-обработки

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

     ROOTFS_PREPROCESS_COMMAND
     ROOTFS_POSTPROCESS_COMMAND
     SDK_POSTPROCESS_COMMAND
     POPULATE_SDK_POST_TARGET_COMMAND
     POPULATE_SDK_POST_HOST_COMMAND
     IMAGE_POSTPROCESS_COMMAND
     IMAGE_PREPROCESS_COMMAND
     ROOTFS_POSTUNINSTALL_COMMAND
     ROOTFS_POSTINSTALL_COMMAND

Для перехода можно просто «обернуть» команды в функции командного процессора (shell) и затем вызывать функции, как показано ниже.

     my_postprocess_function() {
        echo "hello" > ${IMAGE_ROOTFS}/hello.txt
     }
     ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "

4.5.5. Тестирование пакетов (ptest)

Тестирование пакетов (ptest) встроено, но по умолчанию не устанавливается. Работа с тестами описана в разделе Testing Packages with ptest [2], а класс ptest – в параграфе 6.104. ptest.bbclass.

4.5.6. Изменение сборки

Раздельные каталоги для сборки и исходных кодов разрешены по умолчанию для отдельных заданий, где это известно («белый список»), а также для всех заданий, наследующих класс cmake. В будущих выпусках класс autotools будет разрешать также отделение каталога сборки по умолчанию. Программы сборки заданий на основе autotools, которые не могут работать с отдельным каталогом сборки следует изменить, чтобы они могли наследовать класс autotools-brokensep вместо autotools или autotools_stageclasses.

4.5.7. `qemu-native`

Заданиеqemu-native сейчас собирается по умолчанию без графического интерфейса на базе SDL. Для включения графического интерфейса в файле local.conf должны быть приведенные ниже строки⁶.

     PACKAGECONFIG_pn-qemu-native = "sdl"
     ASSUME_PROVIDED += "libsdl-native"

4.5.8. `core-image-basic`

Образcore-image-basic переименован в core-image-full-cmdline,а группаpackagegroup-core-basic – в packagegroup-core-full-cmdline.

4.5.9. Лицензирование

Файл LICENSE верхнего уровня изменен для более точного описания лицензий различных компонент OE-Core без изменения самого лицензирования. Обычно это изменение не вызывает побочных эффектов. Однако некоторые задания указывают этот файл в LIC_FILES_CHKSUM (как ${COREBASE}/LICENSE), поэтому нужно изменить сопровождающую контрольную сумму 3f40d7994397109285ec7b81fdeb3b58 на 4d92cd373abda3937c2bc47fbc49d690. Лучше указывать в LIC_FILES_CHKSUM файл, описывающий лицензию, распространяемую с исходным кодом для сборки задания, а не ${COREBASE}/LICENSE.

4.5.10. Опции `CFLAGS`

Опция -fpermissive удалена из принятого по умолчанию значение CFLAGS. Это нужно учитывать в заданиях, где возникает отказ при сборке без этой опции – задания нужно изменить для устранения ошибок, сообщаемых компилятором, или добавить опцию -fpermissive в переменную CFLAGS для этого задания.

4.5.11. Типы вывода пользовательских образов

Пользовательские типы образов, указанные в переменной IMAGE_FSTYPES, должны объявлять свои зависимости (при наличии) через новую переменную IMAGE_TYPEDEP.

4.5.12. Задачи

Задача do_package_write удалена за ненадобностью.

4.5.13. Поставщик `update-alternative`

Принятый по умолчанию поставщик update-alternatives сменен с opkg на opkg-utils,что позволило решить некоторые проблемы с закольцованными зависимостями. Используемый при работе пакет (runtime) update-alternatives-cworth переименован в update-alternatives-opkg.

4.5.14. Переопределение `virtclass`

Переопределения virtclass устарели и взамен используются эквиваленты (например, virtclass-native вместо class-native).

4.5.15. Удаленные и переименованные задания

packagegroup-toolset-native больше не применяется.
linux-yocto-3.8 – поддержка ядра Linux yocto 3.8 исключена, ядра 3.10 и 3.14 добавлены как задания linux-yocto-3.10 и linux-yocto-3.14.
ocf-linux функционально заменено заданием cryptodev-linux.
genext2fs больше не используется системой сборки и не поддерживается в восходящих разработках.
js – древняя версия движка Mozilla javascript, которая больше не применяется.
zaurusd перенесено на уровень meta-handheld.
eglibc 2.17 заменено заданием eglibc 2.19.
gcc 4.7.2 заменено новым стабильным gcc 4.8.2.
external-sourcery-toolchain поддерживается на уровне meta-sourcery.
linux-libc-headers-yocto 3.4+git — сейчас по умолчанию применяется the linux-libc-headers версии 3.10.
meta-toolchain-gmae отменено.
packagegroup-core-sdk-gmae отменено.
packagegroup-core-standalone-gmae-sdk-target отменено.

4.5.16. Удаленные классы

module_strip;
pkg_metainfo;
pkg_distribute;
image-empty.

4.5.17. Эталонные BSP

Эталонный пакет BeagleBoard ARM (beagleboard) заменен BeagleBone (beaglebone).
Эталонный пакет RouterStation Pro MIPS (routerstationpro) заменен EdgeRouter Lite (edgerouter).

Прежние эталонные BSP для машин beagleboard и routerstationpro сохранены на уровне meta-yocto-bsp-old в дереве исходных кодов репозитория http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto-bsp-old/.

4.6. Переход на YP 1.7

В этом разделе рассмотрен переход на YP 1.7 с предыдущего выпуска.

4.6.1. Изменение опций QEMU `PACKAGECONFIG` в файле `local.conf`

Задание QEMU сейчас применяет множество опций PACKAGECONFIG для управления дополнительными возможностями. Используемый для задания принятых по умолчанию значений этих опций требует изменения имеющегося файла local.conf с целью добавления PACKAGECONFIG для qemu-native и nativesdk-qemu вместо их установки. Иными словами, для добавления графического вывода в QEMU следует включить в файл local.confприведенные ниже строки

     PACKAGECONFIG_append_pn-qemu-native = " sdl"
     PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"

4.6.2. Минимальная версия Git

Сейчас требуется версия Git не ниже 1.7.8, поскольку сборщику Git нужна опция --list. Как обычно, если сборочный хост не соответствует требованиям, можно загрузить и установить архив buildtools(см. параграф 1.3. Требуемые версии Git, tar и Python.

4.6.3. Изменение класса autotools

По умолчанию применяется отдельный каталог сборки. Класс autotools изменен для работы с каталогом сборки (B), отделенным от дерева исходных кодов (S). Это указывается как B != Sили сборка вне дерева.

Если собираемая программа уже позволяет сборку вне дерева, ничего изменять не нужно. Если же программа не поддерживает такой сборки, нужно ее исправить соответствующим образом или изменить задание для наследования класса autotools-brokensep вместо autotools или autotools_stage.
Опция --foreign больше не передается automake при работе autoconf. Эта опция говорит automake,что определенный пакет не соответствует стандартамGNU и поэтому не следует ожидать распространения в нем таких файлов как ChangeLog, AUTHORSи т. п. Поскольку большинство программ уже говорят automake,что они сами включают режимforeign, эта опция стала ненужной. Однако некоторые задания придется все-таки изменить. Это легко сделать, указав в файле configure.ac передачу foreign в AM_INIT_AUTOMAKE().

4.6.4. Отмена сценариев настройки конфигурации

В некоторых заданиях, упаковывающих двоичные сценарии настройки, эти сценарии отключены по причине возникновения ошибок при подстановке путей. Программам, связанным с библиотеками, использующими такие сценарии, следует применять более надежный пакет pkg-config. Список заданий, измененных в этой версии (и их сценариев настройки) включает directfb (directfb-config), freetype (freetype-config), gpgme (gpgme-config), libassuan (libassuan-config), libcroco (croco-6.0-config), libgcrypt (libgcrypt-config), libgpg-error (gpg-error-config), libksba (ksba-config), libpcap (pcap-config), libpcre (pcre-config), libpng (libpng-config, libpng16-config), libsdl (sdl-config), libusb-compat (libusb-config), libxml2 (xml2-config), libxslt (xslt-config), ncurses (ncurses-config), neon (neon-config), npth (npth-config), pth (pth-config), taglib (taglib-config). В дополнение к этому была добавлена поддержка pkg-config в некоторые задания из этого списка, если пакет еще не включал ее.

4.6.5. Замена `eglibc 2.19` на `glibc 2.20`

Поскольку eglibc и glibc уже довольно близки, замена не должна потребовать существенных изменений в программах, связанных с eglibc. Однако в glibc 2.20 внесено множество мелких изменений, которые могут потребовать исправлений в ряде программ (например, удаление макроса тестирования свойств _BSD_SOURCE). Для glibc 2.20 требуется ядро Linux версии 2.6.32 или выше. Дополнительная информация об изменениях в glibc 2.20 доступна по ссылке.

4.6.6. Автоматическая загрузка модулей ядра

Переменные module_autoload_* отменены и вместо них следует использовать новую переменную KERNEL_MODULE_AUTOLOAD. Переменные module_conf_* должны сейчас применяться вместе с новой переменной KERNEL_MODULE_PROBECONF. Эти новые переменные не требуют указания имени модуля как части имени переменной, что не только упрощает использование, но и позволяет аккуратно встраивать значения этих переменных в подписи задач и активизировать повторное выполнение задач при появлении изменений. Следует заменить все включения module_autoload_* на KERNEL_MODULE_AUTOLOADи добавить все модули, для которых заданы переменные module_conf_*, в KERNEL_MODULE_PROBECONF.

4.6.7. Изменения проверки качества (QA)

Добавлены проверки file-rdeps и build-deps для контроля соблюдения зависимостей (например, пакетов, содержащих сценарии, которым требуется /bin/bash) и корректности указания зависимостей при сборке (Глава 10. Ошибки и предупреждения тестов QA).
Проверка качества пакетов выполняется новой задачей do_package_qa, а не do_package task. Это изменение не должно вызывать проблем за исключением сложных пользовательских заданий, которые отключают задачу упаковки, помечая ее как noexec. Для таких пакетов нужно отключать задачу do_package_qa.
Файлы, переписанные при выполнении задачи do_populate_sysroot, теперь вызывают ошибку, а не предупреждение. Заданиям не следует переписывать файлы, записанные в sysroot другими заданиями, и при наличии таких заданий их следует должным образом изменить.

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

4.6.8. Удаленные задания

x-load заменено U-boot SPL для всех Cortex TI SoC. Для более старых плат следует использовать уровень meta-ti.
ubootchart устарело. Добавлено задание bootchart2, служащее функциональной заменой.
Linux-yocto 3.4 – поддержка ядра linux-yocto 3.4 прекращена, поддержка ядер 3.10 и 3.14 сохранена, добавлено ядро 3.17.
eglibc заменено на glibc (см. параграф 4.6.5. Замена eglibc 2.19 на glibc 2.20).

4.6.9. Прочие изменения

Функции записи истории сборки теперь создает вместо build-id файл build-id.txt, который включает полный заголовок сборки, выводимый BitBake при старте. Имеет смысл удалить старые файлы build-id из имеющихся репозиториев сборки для предотвращения путаницы. Функция истории сборки описана в разделе Maintaining Build Output Quality [2].

4.7. Переход на YP 1.8

В этом разделе рассмотрен переход на YP 1.8 с предыдущего выпуска.

4.7.1. Удаленные задания

owl-video функционально заменено gst-player.
gaku функционально заменено gst-player.
gnome-desktop сейчас доступно в meta-gnome и отдельное задание не нужно.
gsettings-desktop-schemas сейчас доступно в meta-gnome и отдельное задание не нужно.
python-argparse – модуль уже предоставляется в используемом по умолчанию дистрибутиве Python в пакете python-argparse, поэтому отдельное задание уже не нужно.
telepathy-python, libtelepathy, telepathy-glib, telepathy-idle, telepathy-mission-control перенесены с meta-oe и поэтому больше не нужны заданиям из OpenEmbedded-Core.
linux-yocto_3.10 и linux-yocto_3.17 – поддержка linux-yocto 3.10 и 3.17 прекращена. Ядро 3.14 поддерживается и добавлено ядро 3.19.
poky-feed-config-opkg устарело и больше не требуется. Вместо него применяется distro-feed-config их meta-oe.
libav 0.8.x – сейчас используется libav 9.x.
sed-native больше не нужно. Предполагается обеспечение рабочей версии sed дистрибутивом хоста.

4.7.2. Выбор BlueZ 4.x или 5.x

Имеется встроенная поддержка BlueZ 5.x предпочтительная по сравнению с используемой по умолчанию 4.x. Для использования BlueZ 5.x достаточно добавить bluez5 в переменную DISTRO_FEATURES. Если ранее выбор был включен в файл добавления (*.bbappend), его можно удалить. Кроме того, был добавлен класс bluetooth для более удобного выбора подходящей поддержки bluetooth в задании. Для использования этого класса в задании добавьте строки по приведенному ниже образцу.

inherit bluetooth
PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"

4.7.3. Изменение сборки ядра

Процесс сборки ядра был изменен, чтобы поместить исходные коды в общую рабочую область и отделить элементы сборки (artifact) в дереве исходных кодов. В теории пути перехода были предоставлены для наиболее распространенных вариантов заданий для сборки ядер, но это может работать не во всех случаях. В частности нужно обеспечить корректность использования переменных ${S} (исходные коды) и ${B} (элементы сборки) в таких функциях, как do_configure и do_install. Для заданий, не наследующих kernel-yocto и не включающих linux-yocto.inc, можно использовать файл linux.inc уровня meta-oe для внесения всех требуемых изменений. Для справки можно воспользоваться ссылкой на обновление файла linux.inc для уровня meta-oe.

Задания, основанные на исходном коде ядра и не наследующие класс module, могут требовать явного указания зависимостей в задаче ядра do_shared_workdir. Например, do_configure[depends] += “virtual/kernel:do_shared_workdir”.

4.7.4. Запрет SSL 3.0 в OpenSSL

SSL 3.0 сейчас отключен при сборке OpenSSL. Это позволяет избежать уязвимости POODLE vulnerability. Если нужно все-таки включить SSL 3.0, это можно сделать в файле добавления (*.bbappend) для задания openssl, удалив -no-ssl3 из переменной EXTRA_OECONF.

4.7.5. Изменение принятого по умолчанию каталога sysroot

Принятые по умолчанию в gcc каталоги sysroot и include перенаправлены в несуществующее место, чтобы отследить использование каталогов хоста в результате отсутствия корректно переданных опций. Это применяется для кросс-компиляторов, используемых при сборке, и создаваемых в SDK. Если изменение вызывает отказ при сборке, это может означать, что флаги и команды компилятора были некорректно переданы базовым программам. В таких случаях нужно внести соответствующие правки.

4.7.6. Улучшение повторной сборки

Изменены классы base, autotools и cmake для очистки созданных файлов при необходимости повтора do_configure. Одним из улучшения является попытка выполнить команду make clean в задаче do_configure, если имеется файл Makefile. Некоторые программы не поддерживают очистки в своих файлах make. Для таких заданий нужно установить CLEANBROKEN = “1”.

4.7.7. Изменения в проверках QA

Использование PRINC ранее вызывало предупреждения, а сейчас приводит к ошибке. Следует удалить использование PRINC из всех заданий и файлов добавления.
Добавлена проверка QA использования ${D} в значениях FILES там, где применять D не следует. Эта проверка гарантирует использование $D в функциях pkg_preinst, pkg_postinst, pkg_prerm, pkg_postrm вместо ${D}.
В переменной S нужно устанавливать действительное для задания значение. Если переменная S в задании не установлена, каталог автоматически не создается. Если S не указывает каталог, существующий к моменту завершения задачи do_unpack, выдается предупреждение.
Проверяется переменная LICENSE на предмет корректности форматирования множества лицензий. Если формат не пригоден (например, указано множество лицензий без оператора, определяющего их взаимодействие), выдается предупреждение.

4.7.8. Прочие изменения

Сценарий send-error-report ожидает опцию -s перед адресом сервера (это предполагает указание сервера).
Сценарий oe-pkgdata-util ожидает опции -“перед каталогом pkgdata, который сейчас можно не указывать. При отсутствии pkgdata сценарий будет запускать BitBake для запроса PKGDATA_DIR в среду сборки.

4.8. Переход на YP 2.0

В этом разделе рассмотрен переход на YP 2.0 с предыдущего выпуска.

4.8.1. GCC 5

По умолчанию используется компилятор GCC 5.2, потребовавшийся для устранения ошибок компиляции во многих заданиях. Одним из важных примеров служит ситуация, когда система «зависала» при сборке ядра Linux для ARM с компилятором GCC 5. При использовании своих заданий, собирающих ядро для ARM, вам может потребоваться внести исправление. В стандартном дереве ядра linux-yocto эти исправления уже внесены. Дополнительная информация приведена на странице https://gcc.gnu.org/gcc-5/changes.html, рекомендации по переносу – на странице https://gcc.gnu.org/gcc-5/porting_to.html.

Можно вернуться к использованию GCC версии 4.9 или 4.8 с помощью строки вида GCCVERSION = “4.9%” в файле конфигурации.

4.8.2. Удаление Gstreamer 0.10

Поддержка Gstreamer 0.10 была заменена поддержкой Gstreamer 1.x. В результате этого изменения задания для Gstreamer 0.10 и связанных программ размещены сейчас в meta-multimedia. Это ведет к тому, что в Qt4 поддержка Phonon и Gstreamer до умолчанию отключена для QtWebkit.

4.8.3. Удаленные задания

bluez4 устарело и перемещено в meta-oeв результате полной интеграции с bluez5.
gaminустарело и удалено.
gnome-icon-theme функционально заменено заданием adwaita-icon-theme.
Задания Gstreamer 0.10 удалены в пользу поддержки заданий для Gstreamer 1.x.
insserv устарело и удалено.
libunique больше не используется и перенесено в meta-oe.
midori функционально заменено заданием epiphany.
python-gst устарело и было удалено, поскольку требовалось только для Gstreamer 0.10.
qt-mobility устарело и было удалено, поскольку требует наличия Gstreamer 0.10(удалено).
subversion удалены версии 1.6.x этого задания.
webkit-gtk старая версия 1.8.3 удалена с заменой на webkitgtk.

4.8.4. Улучшение хранилища данных BitBake

Изменен метод обработки переопределений хранилищем BitBake. Переопределения сейчас применяются динамически, а bb.data.update_data() не используется. На практике это изменение вряд ли потребует какого-либо изменения метаданных. Однако имеются незначительные изменения в поведении, указанные ниже.

Все возможные переопределения теперь доступны в истории по команде bitbake -e.
d.delVar('VARNAME') и d.setVar('VARNAME', None) приводят к очистке переменной и всех ее переопределений. До изменения очищались лишь не переопределенные значения.

4.8.5. Смена поведения shell-функций

Консольные (shell) версии функций сообщений BitBake (bbdebug, bbnote, bbwarn, bbplain, bberror, bbfatal) связаны с их эквивалентами в BitBake – bb.debug(), bb.note(), bb.warn(), bb.plain(), bb.error(), bb.fatal(), соответственно. Таким образом, функции сообщений, ожидаемые в пользовательском интерфейсе BitBake UI, будут выводиться фактически. На практике это изменение имеет два проявления, описанных ниже.

Если на консоли появляются сообщения, которых ранее (до изменения) не было, может потребоваться очистка вызовов bbwarn, bberrorи т. п. Можно просто удалить эти вызовы.
Функция bbfatal подавляет полный вывод журнала ошибок в UI, поэтому при необходимости видеть этот вывод полностью нужно заменить bbfatal на die или bbfatal_log.

4.8.6. Очистка дополнительных пакетов для разработки и отладки

Удалены использованные при разработке и отладке задания для acl, apmd, aspell, attr, augeas, bzip2, cogl, curl, elfutils, gcc-target, libgcc, libtool, libxmu, opkg, pciutils, rpm, sysfsutils, tiff, xz.Для всех перечисленных заданий сейчас применяется стандартная схема, где для задания имеется один пакет-dev, -dbg, -staticdev.

4.8.7. Перенос данных отслеживания заданий в OE-Core

Поддержка данных отслеживания для заданий, которые были частью meta-yocto, перенесена на уровень OE-Core. Это относится к файлам package_regex.inc и distro_alias.inc, которые обычно включаются при использовании класса distrodata. Кроме того, содержимое файла upstream_tracking.inc теперь разделено по заданиям.

4.8.8. Автоматическая очистка устаревших файлов в sysroot

Файлы из заданий, которых уже нет в текущей конфигурации, автоматически удаляются из sysroot и других мест, управляемых общим состоянием. Эта автоматическая очистка означает, что система сборки корректно обрабатывает такие ситуации, как переименования сборочной стороны заданий, удаление уровней из bblayers.conf и изменение DISTRO_FEATURES.

В дополнение к этому очищаются каталоги старых версий заданий. Если нужно отключить такую очистку, можно установить в конфигурации переменную SSTATE_PRUNE_OBSOLETEWORKDIR = “0”.

4.8.9. Репозиторий метаданных linux-yocto отделен от исходного кода

Дерево linux-yocto до этого представляло набор изменений в ядре и конфигурации (метаданных). Хотя такой формат эффективен для синхронизации конфигураций ядра и изменений в исходных кодах, разработчикам не всегда понятно, как работать с метаданными применительно к исходным кодам.

Обработка метаданные перенесена из класса kernel-yocto и применяется внешний репозиторий метаданных yocto-kernel-cache, который всегда использовался для заполнения ветви meta в linux-yocto. Отдельный репозиторий кэша linux-yocto сейчас служит основным местом хранения для этих данных. В результате linux-yocto больше не может обрабатывать комбинированные деревья. Поэтому при необходимости иметь свой комбинированный репозиторий ядра нужно будет разделить его и соответственно обновить свои задания. Примером может служить задание meta/recipes-kernel/linux/linux-yocto_4.1.bb.

4.8.10. Дополнительные проверки QA

Добавлена проверка host-user-contaminated для контроля вопросов владения файлами за пределами /home. Проверка ищет файлы, некорректно принадлежащие пользователю, запустившему BitBake, а не предусмотренному пользователю в целевой системе.
Добавлена проверка invalid-chars для обнаружения недействительных (не-UTF8) символов в значениях переменных метаданных задания (DESCRIPTION, SUMMARY, LICENSE, SECTION), поскольку некоторые менеджеры пакетов не поддерживают такие символы.
Добавлена проверка invalid-packageconfig опций PACKAGECONFIG на соответствие опциям задания.

4.8.11. Прочие изменения

gtk-update-icon-cache переименовано в gtk-icon-utils.
Элемент tools-profile в IMAGE_FEATURES, а также соответствующие packagegroup и packagegroup-core-tools-profile больше не включаются в oprofile. Внедрение в oprofile изначально было предназначено для облегчения компиляции для платформ с ограниченными ресурсами. Однако это не получило широкого распространения и вряд ли будет применяться в будущем по причине расширения возможностей платформ и усовершенствования инструментов кросс-компиляции.
Принятое по умолчанию значение переменной IMAGE_FSTYPES включает ext4 вместо ext3.
Удалена поддержка переменной PRINC.
Группа пакетов packagegroup-core-full-cmdline больше не используется в lighttpd по причине того, что это не соответствует назначению packagegroup, которое заключается в добавлении консольных инструментов, которые по умолчанию обеспечиваются busybox.

4.9. Переход на YP 2.1

В этом разделе рассмотрен переход на YP 2.1 с предыдущего выпуска.

4.9.1. Преобразование переменных в функциях Python

Выражения для переменных вида ${VARNAME} больше не преобразуются автоматически в функциях Python. Это сделано для того, чтобы позволить функциям Python создавать shell-сценарии и другой код для ситуаций, где не нужны такие преобразования. В имеющемся коде, который применяет такие преобразования, нужно изменить их для преобразования отдельных переменных с помощью d.getVar() или d.expand() для более сложных выражений.

4.9.2. Нижний регистр для переменной `OVERRIDES`

В соглашении о переопределениях всегда предполагались символы нижнего регистра. Это стало сейчас требованием, поскольку хранилище BitBake предполагает нижний регистр символов для некоторого ускорения процесса анализа. На практике это означает, что все завершающееся в OVERRIDES должно указываться символами нижнего регистра (например, значения MACHINE, TARGET_ARCH, DISTRO, а также имена заданий, если действуют переопределения _pn-recipename).

4.9.3. Параметр раскрытия функций `getVar()` и `getVarFlag()` стал обязательным

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

     sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *`
     sed -e 's:\(\.getVarFlag([^,()]*, [^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *`

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

4.9.4. Изменение окружения Makefile

Переменная EXTRA_OEMAKE сейчас имеет по умолчанию значение “” вместо прежнего “-e MAKEFLAGS=”, что было исторической случайностью, требовавшей переопределения во множестве классов (например, autotools, module) и заданий. При обновлении на этот выпуск нужно отредактировать все задания, основанные на прежнем значении, путем возврата “-e MAKEFLAGS=” или явной установки нужного значения EXTRA_OEMAKE, что обычно требуется только в случаях установки Makefile по умолчанию не подходящего для кросс-компиляции значения переменной с использованием оператора =, а не ?=.

4.9.5. Возвращение `libexecdir` к `${prefix}/libexec`

Использование ${libdir}/${BPN} в качестве libexecdir отличается от всех основных дистрибутивов, применяющих ${prefix}/libexec или ${libdir}, и противоречит стандартам кодирования GNU, задающим использование ${prefix}/libexec, а также практике задания используемой пакетом вложенности в самом пакете. Кроме того, различия libexecdir в разных заданиях осложняют этим заданиям вызов двоичных файлов, установленных в libexecdir. Стандарт FHS 7 признает использование ${prefix}/libexec/, предоставляя приложениям выбор между ${prefix}/lib и ${prefix}/libexec.

4.9.6. ac_cv_sizeof_off_t больше не кэшируется в файлах сайта

Для заданий, наследующих класс autotools, значение ac_cv_sizeof_off_t больше не кэшируется в файлах сайта для autoconf. Причина этого заключается в том, что ac_cv_sizeof_off_t не обязательно является неизменным для архитектуры, как считалось ранее, и меняется в зависимости от поддержки больших файлов. Для большинства программ, использующих autoconf, внесенное изменение не создает проблем. Однако задания, которые обходят стандартную задачу do_configure из класса autotools, и программ использующих очень старые версии autoconf, задание может не определить корректный размер off_t в процессе выполнения задачи do_configure.

Лучшим вариантом действий является исправление программ при необходимости, чтобы принятая по умолчанию реализация из класса autotools работала так, чтобы выполнялась утилита autoreconf, создающая работоспособный сценарий configure, и переопределение задачи do_configure для использования принятой по умолчанию реализации.

4.9.7. Генерация образа отделена от генерации файловой системы

Ранее задача do_rootfs для образов собирала файловую систему и помещала в нее созданные образы. С этого выпуска YP генерация образов вынесена в отдельные задачи do_image_*, чтобы отделить операции от кода.

В большинстве случаев это изменение не вызовет проблем. Однако при наличии настроек, непосредственно меняющих задачу do_rootfs или или ссылку на нее, может потребоваться внесение изменений. В частности, при добавлении любых задач после do_rootfs следует изменить эти задачи так, чтобы они выполнялись после do_image_complete, а не после do_rootfs для соблюдения корректного порядка выполнения.

Еще одна часть этого изменения заключается в переносе определений и функций пост-обработки из класса image в класс rootfs-postcommands. Функционально это ничего не меняет.

4.9.8. Удаленные задания

gcc версии 4.8 – версии 4.9 и 5.3 сохранены;
qt4 – поддержка Qt 4.x перенесена в отдельный уровень meta-qt4;
x11vnc перенесено на уровень meta-oe;
linux-yocto-3.14;
linux-yocto-3.19;
libjpeg заменено заданием libjpeg-turbo;
pth признано устаревшим;
liboil больше не нужно и перенесено на уровень meta-multimedia;
gtk-theme-torturerбольше не нужно и перенесено на уровень meta-gnome;
gnome-mime-data больше не нужно и перенесено на уровень meta-gnome;
udev заменено заданием eudev для совместимости при использовании sysvinit с новыми ядрами;
python-pygtk признано устаревшим;
adt-installer признано устаревшим (см. параграф 4.9.11. Удаление ADT).

4.9.9. Изменения классов

autotools_stage удален в результате обеспечения нужной функциональности классом autotools. Заданиям, наследовавшим autotools_stage сейчас нужно наследовать autotools.
boot-directdisk слит с классом image-vm. Класс boot-directdisk применялся редко и изменение не должно вызывать проблем.
bootimg слит с классом image-live. Класс bootimg применялся редко и изменение не должно вызывать проблем.
packageinfo удален, поскольку применялся лишь в удаленном интерфейсе Hob UI.

4.9.10. Изменения пользовательского интерфейса системы сборки

Интерфейс Hob UI на базе GTK+ удален, поскольку больше не поддерживается и основан на устаревшей библиотеке GTK+ 2. Интерфейс Toaster UI на основе web более эффективен и активно поддерживается (см. раздел Using the Toaster Web Interface [8]).
Интерфейс “puccho” BitBake UI удален, поскольку больше не поддерживается и малополезен.

4.9.11. Удаление ADT

Пакет разработки приложений ADT⁸ был удален, поскольку его функциональность практически полностью перекрывалась со стандартным SDK и расширенным SDK [7]. Плагин Yocto Project Eclipse IDE не затронут изменением.

4.9.12. Изменения в эталонном дистрибутиве Poky

Уровень meta-yocto переименован в meta-poky, что точнее отражает его назначение - эталонный дистрибутив Poky. Уровень meta-yocto-bsp сохранил свое имя, поскольку он содержит эталонные машины для YP и больше никак не связан с Poky. Ссылки на meta-yocto в файле conf/bblayers.conf должны обновиться автоматически.
Класс uninative включен в Poky по умолчанию. Этот класс пытается изолировать систему сборки от библиотеки C дистрибутива хоста и делает возможным использование естественных элементов общего состояния разными дистрибутивами хоста. При включенном класса загружается архив собранной библиотеки C в начале сборки. Класс uninative включается в файле meta/conf/distro/include/yocto-uninative.inc, что позволяет управлять им независимо от использования дистрибутива Poky.

Если нужно собрать свой архив uninative, это можно сделать с помощью задания uninative-tarball и сделать архив доступным для сборочных машин (например, по протоколу HTTP/HTTPS), а также установить похожую на yocto-uninative.inc конфигурацию.
Генерация статических библиотек сейчас по умолчанию отключена в Poky для большинства классов. Это сократило время сборки и также размер области сборки. Запрет создания таких библиотек задан в файле meta/conf/distro/include/no-static-libs.inc. В задания, которым не нужна опция –disable-static в команде configure, следует включить переменную DISABLE_STATIC = “”.
В отдельном компактном дистрибутиве poky-tiny сейчас применяется библиотека musl C вместо сильно урезанной glibc. Использование musl уменьшает размер дистрибутива и упрощает поддержку. При использовании poky-tiny со своей конфигурацией glibc нужно будет изменить настройки в новом выпуске.

4.9.13. Изменения в пакетах

Двоичные файлы runuser и mountpoint из пакета util-linux перенесены в util-linux-runuser и util-linux-mountpoint.
Пакет python-elementtree объединен с пакетом python-xml.

4.9.14. Изменения в файлах настройки

Функция настройки no-thumb-interwork удалена из включаемых файлов настройки ARM, поскольку для ARM EABI требуется взаимодействие, эта функция не имеет смысла.
Отменена поддержка ARM OABI в gcc 4.7.
Удалены файлы tune-cortexm*.inc и tune-cortexr4.inc, поскольку они не были достаточно протестированы. Пока система сборки OE не будет официально поддерживать CPU без MMU, эти файлы лучше держать на отдельном уровне, если они нужны.

4.9.15. Поддержка GObject Introspection

Этот выпуск поддерживает генерацию файлов GIR⁹ с помощью самоанализа GObject, который является стандартным механизмом доступа к программам на основе GObject. Можно включать, отключать и тестировать генерацию таких данных, как описано в разделе Enabling GObject Introspection Support [2].

4.9.16. Прочие изменения

Минимальная версия Git заменена на 1.8.3.1. Если сборочных хост имеет более старую версию, следует установить нужные пакеты, как указано в параграфе 1.3. Требуемые версии Git, tar и Python.
Ошибочная и неполная поддержка менеджера пакетов RPM версии 4 была удалена. Проверенная и поддерживаемая версия 5 для RPM сохранена.
Ранее было указано, что удаляются пакеты update-rc.d, base-passwd, shadow, update-alternatives, run-postinsts, если package-management нет в IMAGE_FEATURES. В выпуске YP 2.1 эти пакеты удаляются лишь при наличии read-only-rootfs в IMAGE_FEATURES, поскольку они могут требоваться для образов с доступом на чтение и запись даже при отсутствии менеджера пакетов (например, для добавления, изменения или удаления пользователей в процессе работы).
Команда devtool modify по умолчанию извлекает исходный код в соответствии с ожиданиями. Опции -x и –extract больше не работают. Если нужно указать свое дерево исходных кодов, следует задать опцию -n или –no-extract для команды devtool modify.
Если форм-фактор для машины не указан или не говорит о наличии клавиатуры, это наличие предполагается по умолчанию. Основное влияние это изменение оказывает на Sato UI.
Каталоги упаковки .debug создаются автоматически. Если задание собирает пакеты, которые устанавливают двоичные файлы в нестандартные каталоги, больше не нужно заботиться об установке FILES_${PN}-dbg для указания каталогов .debug.
Неточные данные о процентах занятости диска и CPU удалены из вывода buildstats с заменой данными getrusage() и корректной статистикой ввода-вывода. Возможно потребуется обновление пользовательского кода для чтения данных buildstats.
Файл meta/conf/distro/include/package_regex.inc отменен с переносом содержимого в отдельные задания. Поскольку этот файл скорей всего будет удален в новых выпусках YP, предлагается убрать все ссылки на него из вашей конфигурации.
Файл v86d/uvesafb удален из эталонных машин genericx86 и genericx86-64 уровня meta-yocto-bsp. Большинство современных плат x86 не использует этот файл и он лишь добавляет сообщения об ошибках ядра при запуске. Если поддержка uvesafb нужна, можно добавить v86d в образ.
Пути сборки sysroot удалены из файлов с отладочными символами. Это означает, что удаленный отладчик GDB, использующий невырезанные символы сборки sysroot, больше не сможет работать (хотя такая работа никогда и не документировалась). Поддерживаемым методом для выполнения похожих операций является установка IMAGE_GEN_DEBUGFS = “1”, при которой будет создаваться сопровождающий отладочный образ вместе с данными для отладки.

4.10. Переход на YP 2.2

В этом разделе рассмотрен переход на YP 2.2 с предыдущего выпуска.

4.10.1. Минимальная версия ядра

Минимальная версия ядра для целевых платформ и SDK сейчас 3.2.0 в результате перехода на glibc 2.24. Для платформ AArch64 нужна версия 3.14, для Nios II – 3.19. Для систем x86 и x86_64 при необходимости можно сбросить OLDEST_KERNEL до версии 2.6.32.

4.10.2. Упрощено упорядочение каталогов в sysroot

Упорядочение каталогов в sysroot упрощено и добавлены переменные SYSROOT_DIRS, SYSROOT_DIRS_NATIVE и SYSROOT_DIRS_BLACKLIST. Дополнительная информация приведена в списке рассылки OE-Core ( v2 patch series).

4.10.3. Включено удаление старых образов и других файлов из `tmp/deploy`

Удаление старых образов и других файлов из tmp/deploy/ включено по умолчанию в результате использования для этих файлов нового метода подготовки. В результате переменная RM_OLD_IMAGE стала избыточной.

4.10.4. Изменения Python

4.10.4.1. BitBake требует Python 3.4+

BitBake требует Python версии 3.4 или выше.

4.10.4.2. На сборочном хосте требуется UTF-8 Locale

Python 3 требует на сборочном хосте установки UTF-8. Поскольку C.UTF-8 не является стандартом, по умолчанию применяется en_US.UTF-8.

4.10.4.3. Метаданные должны использовать синтаксис Python 3

Для метаданных теперь требуется синтаксис Python 3. Рекомендации по подготовке метаданных можно найти в любом из руководств по переносу в Python 3. Можно также согласиться на фиксации (commit) преобразования для Bitbake и использовать OE-Core в качестве руководства. Ниже перечислены наиболее важные области.

Конвейеры командной строки субпроцессов требуют декодирования locale.
Изменен синтаксис восьмеричных значений.
Изменены имена функции iter*().
Итерации возвращают представления (view), а не списки.
Изменены имена модулей Python.

4.10.4.4. Задания Python для целевых платформ переключены на Python 3

Большинство заданий Python для целевых платформ переведены на Python 3. К сожалению, системы с менеджером пакетов RPM и его поддержкой через SMART продолжают использовать Python 2.

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

4.10.4.5. Архив `buildtools` включает Python 3

Архив buildtools сейчас включает Python 3.

4.10.5. Замена uClibc на musl

Библиотека uClibc была заменена библиотекой musl, которая лучше разработана, широко поддерживается и совместима с большим числом приложений, нежели uClibc.

4.10.6. `${B}` больше не служит для задач рабочим каталогом по умолчанию

${B} больше не является принятым по умолчанию рабочим каталогом для задач. Поэтому все пользовательские задачи должны иметь флаг [dirs] или в задачах рабочий каталог должен быть указан вручную (например, командой cd). Предпочтительно использовать флаг [dirs].

4.10.7. Сценарий `runqemu` переписан на Python

Сценарий runqemu был переписан на Python и поведение в некоторых случаях изменилось. Прежние шаблоны поведения поддерживаются.

В новом сценарии runqemu на Python информация о машине уже не задана жестко и можно выбрать использование конфигурационного файла qemuboot,чтобы определить собственные аргументы BSP и сделать его загружаемым с помощью runqemu. Конфигурационный файл имеет форму image-name–machine.qemuboot.conf.

Файл конфигурации включает тонкую настройку опций, передаваемых QEMU без жесткого кодирования сценария runqemu и информации о разных машинах. Использование конфигурационного файла удобно, в частности, при попытке использования QEMU с машинами, отличающимися от qemu* в OE-Core. Файл qemuboot.conf создается классом qemuboot при сборке корневой файловой системы (rootfs). Аргументы загрузки QEMU могут быть заданы в конфигурационном файле BSP и класс qemuboot сохранит их в qemuboot.conf.

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

$ runqemu machine rootfs kernel [options]

Поддерживаются машины qemuarm, qemuarm64, qemux86, qemux86-64, qemuppc, qemumips, qemumips64, qemumipsel, qemumips64el.

Рассмотрим пример использования машины qemux86-64, обеспечивающий корневую файловую систему, образ и использование опции nographic.

$ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic

Ниже приведен список переменных, которые могут быть установлены в конфигурационном файле (например, bsp.conf) для загрузкиBSP с помощью runqemu.

"QB" means "QEMU Boot". 
QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386")
QB_OPT_APPEND: Options to append to QEMU (e.g. "-show-cursor")
QB_DEFAULT_KERNEL: Default kernel to boot (e.g. "bzImage")
QB_DEFAULT_FSTYPE: Default FSTYPE to boot (e.g. "ext4")
QB_MEM: Memory (e.g. "-m 512")
QB_MACHINE: QEMU machine (e.g. "-machine virt")
QB_CPU: QEMU cpu (e.g. "-cpu qemu32")
QB_CPU_KVM: Similar to QB_CPU except used for kvm support (e.g. "-cpu kvm64")
QB_KERNEL_CMDLINE_APPEND: Options to append to the kernel's -append
		option (e.g. "console=ttyS0 console=tty")
QB_DTB: QEMU dtb name
QB_AUDIO_DRV: QEMU audio driver (e.g. "alsa", set it when support audio)
QB_AUDIO_OPT: QEMU audio option (e.g. "-soundhw ac97,es1370"), which is used
		when QB_AUDIO_DRV is set.
QB_KERNEL_ROOT: Kernel's root (e.g. /dev/vda)
QB_TAP_OPT: Network option for 'tap' mode (e.g. "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no 
		-device virtio-net-device,netdev=net0").
		runqemu will replace "@TAP@" with the one that is used, such as tap0, tap1 ...
QB_SLIRP_OPT: Network option for SLIRP mode (e.g. "-netdev user,id=net0 -device virtio-net-device,netdev=net0")
QB_ROOTFS_OPT: Used as rootfs (e.g.
		"-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0").
		runqemu will replace "@ROOTFS@" with the one which is used, such as
		core-image-minimal-qemuarm64.ext4.
QB_SERIAL_OPT: Serial port (e.g. "-serial mon:stdio")
QB_TCPSERIAL_OPT: tcp serial port option (e.g.
		" -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -
		device      virtconsole,chardev=virtcon"
		runqemu will replace "@PORT@" with the port number which is used.

Для использования runqemu, устанавливается переменная IMAGE_CLASSES += “qemuboot” и запускается runqemu.

Синтаксис командной строки можно узнать с помощью команды runqemu help.

4.10.8. Изменен стиль хеширования принятого по умолчанию компоновщика

Компоновщик теперь по умолчанию применяет для кросс-компиляции gcc стиль хэширования sysv, чтобы перехватывать задания, создающие программы без использования LDFLAGS. Это изменение может создавать некоторые QA при сборке таких заданий в виде сообщений No GNU_HASH10. Для решения проблемы нужно изменить эти задания, чтобы они применяли LDFLAGS. В зависимости от способа сборки (например, Makefile) может потребоваться исправление системы сборки. Иногда достаточно добавить TARGET_CC_ARCH += “${LDFLAGS}”.

4.10.9. `KERNEL_IMAGE_BASE_NAME` больше не использует `KERNEL_IMAGETYPE`

Переменная KERNEL_IMAGE_BASE_NAME больше не использует KERNEL_IMAGETYPE для создания базового имени образа. Поскольку система сборки OE может создавать множество типов образов ядра, эта часть базового имени была удалена, а сохранено лишь KERNEL_IMAGE_BASE_NAME ?= “${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}. При наличии заданий или классов, использующих KERNEL_IMAGE_BASE_NAME напрямую, может потребоваться обновление ссылок.

4.10.10. BitBake

Инструменты goggle UI и автономный image-writer удалены, поскольку им нужна поддержка GTK+ 2.0.
Сборщик Perforce сейчас поддерживает SRCREV для указания используемого выпуска исходного кода (${AUTOREV}, номер списка изменений, p4date или метка) вместо отдельных параметров SRC_URI. Это изменение больше соответствует другим сборщикам, работающим с системами контроля версий. Задания, использующие Perforce, следует обновить для работы с SRCREV вместо SRC_URI.
Нужно изменить некоторые внутренние структуры кода BitBake для доступа к кэшу заданий с целью поддержки новой функциональности с множеством конфигураций. Эти изменения будут влиять на внешние инструменты, применяемые в BitBake модулем tinfoil. Информация об этих изменениях доступна в описаниях изменений сценариев из состава OpenEmbedded-Core (1 и 2).
Переписан код управления задачами для предотвращения использования косвенных идентификаторов, что позволило повысить производительность. Это изменение не должно вызывать проблем для большинства пользователей. Однако для проверки подписей нужна функция setscene, указываемая переменной BB_SETSCENE_VERIFY_FUNCTION. Поэтому добавлена переменная BB_SETSCENE_VERIFY_FUNCTION2, разрешающая нескольким версиям BitBake работать с подходящими метаданными, включая OpenEmbedded-Core и Poky. При использовании своих планировщиков задач BitBake может потребоваться обновление кода для работы с новой структурой.

4.10.11. Удален инструмент Swabber

Инструмент Swabber, предназначенный для обнаружения «мусора» в процессе сборки, был удален, поскольку некоторое время не поддерживается и никогда не был достаточно эффективным. Система сборки OE включает ряд механизмов (в том числе проверки QA), позволяющих обойтись без этого инструмента.

4.10.12. Удаленные задания

augeas больше не требуется и перенесено в meta-oe.
directfb не поддерживается и перенесено в meta-oe.
gcc – удалена версия 4.9 с сохранением версий 5.4 и 6.2.
gnome-doc-utils больше не требуется.
gtk-doc-stub заменено gtk-doc.
gtk-engines больше не требуется и перенесено в meta-gnome.
gtk-sato-engine устарело.
libglade больше не требуется и перенесено в meta-oe.
libmad не поддерживается и функционально заменено libmpg123 с переносом libmad в meta-oe.
libowl устарело.
libxsettings-client больше не требуется.
oh-puzzles функционально заменено puzzles.
oprofileui устарело. OProfile в значительной степени вытеснен perf.
packagegroup-core-directfb.bb.
core-image-directfb.bb.
pointercal больше не требуется и перенесено в meta-oe.
python-imaging больше не требуется и перенесено в meta-python
python-pyrex больше не требуется и перенесено в meta-python.
sato-icon-theme устарело.
swabber-native – утилита удалена Swabber (параграф 4.10.11. Удален инструмент Swabber).
tslib больше не требуется и перенесено в meta-oe.
uclibc удалено с заменой на musl.
xtscal больше не требуется и перенесено в meta-oe.

4.10.13. Удаленные классы

distutils-native-base больше не требуется.
distutils3-native-base больше не требуется.
sdl устанавливает лишь переменные DEPENDS и SECTION, которые лучше назначать в задании.
sip практически не применялся.
swabber (см. параграф 4.10.11. Удален инструмент Swabber).

4.10.14. Второстепенные изменения в пакетах

grub – grub-editenv перенесен в отдельный пакет.
systemd – связанные с container и vm блоки выделены в новый пакет systemd-container.
util-linux – prlimit выделен в пакет util-linux-prlimit.

4.10.15. Прочие изменения

Файлpackage_regex.inc удален в результате переноса определений в соответствующие задания.
Команды devtool add и recipetool create используют по умолчанию фиксированное значение SRCREV при сборке из репозиториев Git. Значение можно переопределить с помощью опции -a или ‐‐autorev для использования во всех случаях ${AUTOREV}.
distcc интерфейс GTK+ UI по умолчанию отключен.
packagegroup-core-tools-testapps – удалено Piglit.
image.bbclass – COMPRESS(ION) переименована в CONVERSION. Это означает замену COMPRESSIONTYPES, COMPRESS_DEPENDS и COMPRESS_CMD на CONVERSIONTYPES, CONVERSION_DEPENDS и CONVERSION_CMD. Имена переменных COMPRESS* будут работать в выпуске 2.2, но метаданные, которым не нужна совместимость с прежними версиями, следует переименовать, поскольку COMPRESS* в будущих выпусках не планируется поддерживать.
gtk-doc – доступна полная версия. Однако некоторые старые программы могут оказаться не способными применять новую версию для создания документации. Нужно изменить задания, собирающие такие программы, для явного запрета создания документации с помощью gtk-doc.

4.11. Переход на YP 2.3

В этом разделе рассмотрен переход на YP 2.3 с предыдущего выпуска.

4.11.1. Sysroot для задания

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

Объявление зависимостей при сборке. Поскольку это новая возможность, нужно явно объявить все зависимости при сборке задания. Если зависимости не указать, они не будут включены в sysroot для задания.
Указание зависимостей естественных инструментов предустановки и пост-установки. Нужно конкретно указать все зависимости от естественных инструментов для сценариев pkg_preinst и pkg_postinst с помощью переменной PACKAGE_WRITE_DEPS. Это обеспечит доступность инструментов при необходимости запуска сценариев на хосте сборки при выполнении задачи do_rootfs.

Рассмотрим, например, задание dbus,которое имеет сценарийpkg_postinst,вызывающийsystemctl,если systemd имеется в переменной DISTRO_FEATURES. В этом случае systemd-systemctl-native добавляется в переменную PACKAGE_WRITE_DEPSс учетом наличияsystemd в переменной DISTRO_FEATURES.
Проверка заданий, использующих SSTATEPOSTINSTFUNCS. Функции, добавленные в SSTATEPOSTINSTFUNCS,вызываются как в прежних выпускахYP. Однако в результате того, что sysroot сейчас заполняется отдельно для каждого задания при наличии перемещений в функциях, вызываемых через SSTATEPOSTINSTFUNCS нужно будет внести изменения для использования сценария пост-установки, установленного функцией, добавленной в SYSROOT_PREPROCESS_FUNCS. Примером может служить класс pixbufcache в каталоге meta/classes/ Yocto Project Source Repositories.

Сама переменная SSTATEPOSTINSTFUNCS сейчас отменена с заменой на задачу do_populate_sysroot[postfuncs]. Поэтому при наличии функций, которые нужно вызывать после создания sysroot для задания, разумно будет предпринять шаги для использования сценария пост-установки, как описано выше. Это подготовит код к удалению SSTATEPOSTINSTFUNCS в будущем выпуске YP.
Указание sysroot при использовании некоторых внешних сценариев. Поскольку общий каталог sysroot сейчас отсутствует, сценарии oe-find-native-sysroot и oe-run-native были изменены так, что требуется указать какое задание используется в STAGING_DIR_NATIVE.

Дополнительная информация о работе sysroot для заданий приведена в параграфе 6.127. staging.bbclass.

4.11.2. Переменная `PATH`

В среде, используемой для работы задач сборки, переменная PATH теперь очищается с удалением естественных путей (/bin, /sbin, /usr/bin и т. п.) и символьные ссылки указывают только на двоичные файлы сборочного хоста, указанные в переменных HOSTTOOLS и HOSTTOOLS_NONFATAL,добавленных вPATH. Поэтому все естественные двоичные файлы, предоставляемые хостом, должны включаться в эти две переменные на уровне настройки.

Другим вариантом является добавление задания -nativeв переменнуюDEPENDS. Переменная PATH в этом случае не очищается в devshellтаким же способом, поскольку это создало бы проблемы при запуске инструментов хоста в среде разработки.

4.11.3. Изменение сценариев

oe-find-native-sysroot – применение сценария изменилось и имеет форму
```
$ . oe-find-native-sysroot recipe
```
Сейчас задание должно указываться как часть команды, что до версии YP 2.7.1 не требовалось.
oe-run-native – применение сценария изменилось и имеет форму
```
$ oe-run-native native_recipe tool
```
Сейчас естественное задание должно указываться как часть команды, что до версии YP 2.7.1 не требовалось.
cleanup-workdir – удален в результате обнаружения наносимых им повреждений дерева сборки (удаление файлов). Вместо удаления части TMPDIR рекомендуется удалять TMPDIR полностью и восстанавливать из общего состояние (sstate) при последующей сборки.
wipe-sysroot удален, поскольку больше не требуется.

4.11.4. Изменения функций

Ранее отмененные функции bb.data.getVar(), bb.data.setVar()удалены с заменой наd.getVar(), d.setVar()и т. п. Следует исправить ссылки на старые функции.

4.11.5. BitBake

Заменен интерфейс depexp. Графический интерфейс исследования зависимостей BitBake depexp заменен интерфейсом taskexp (Task Explorer), обеспечивающим графическое представление файла task-depends.dot. Представляемые этим интерфейсом данные более точны, нежели данные depexp. Визуализация данных является часто запрашиваемой функцией, поскольку стандартные средства просмотра файлов *.dot зачастую не справляются с размером task-depends.dot.
Изменен вывод bitbake -g. Файлы package-depends.dot и pn-depends.dot,которые раньше создавались командойbitbake -g,удалены. Сейчас генерируется файл recipe-depends.dot,являющийся сокращенным вариантомtask-depends.dot. Это изменение вызвано тем, что файлы package-depends.dot и pn-depends.dotв значительной степени относятся ко времени до выполнения на основе задач и не учитывают зависимостей между заданиями, что может вводить в заблуждение.
Изменение переменных для зеркал. Переменные для зеркал, включая MIRRORS, PREMIRRORS и SSTATE_MIRRORS позволяют теперь разделять значения пробелами, поэтому больше не нужно использовать \\n. BitBake ищет пары значений, что упрощает использование. Для имеющихся переменных не должно требоваться каких-либо изменений.
Сборщик SVN использует параметр ssh, а не rsh. Этот новый необязательный параметр используется при установке protocol = svn+ssh. Параметр может применяться лишь для указания программы ssh, используемой SVN. Сборщик SVN передает параметр через переменную SVN_SSH при выполнении задачи do_fetch. Дополнительная информация приведена в разделе Subversion (SVN) Fetcher (svn://).
Удалены BB_SETSCENE_VERIFY_FUNCTION и BB_SETSCENE_VERIFY_FUNCTION2, поскольку применявший их механизм больше не используется для связанных с заданиями систем sysroot.

4.11.6. Абсолютные символьные ссылки

Абсолютные символьные ссылки (symlink) больше не разрешены в промежуточных (stage) файлах и вызывают ошибку. Для явного создания символьных ссылок может использоваться сценарий lnr, который заменяет команду ln -r. Если сценарий сборки в создаваемой заданием программе создает абсолютные символьные ссылки, которые нужно исправлять, можно наследовать в задании класс relative_symlinks для преобразования ссылок в относительные.

4.11.7. Версии GPLv2 для заданий GPLv3 перенесены

Старые GPLv2-версии заданий GPLv3 перенесены на отдельный уровень meta-gplv2. При использовании INCOMPATIBLE_LICENSE для исключения GPLv3 или PREFERRED_VERSION для подстановки GPLv2-версий заданий GPLv3 нужно добавить в конфигурацию уровень meta-gplv2, доступный
по ссылке.

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

Долгосрочным решением может быть переход на компоненты с лицензией BSD, заменяющие компоненты GPLv3, если требуется исключить лицензии GPLv3 из системы. Это решение будет исследовано в новых выпусках YP.

4.11.8. Изменение управления пакетами

Менеджер пакетов Smart был заменен на DNF. Smart больше не разрабатывается и не перенесен на Python 3.x. Единственным кандидатом на замену оказался пакет DNF.

Изменение функциональности заключается в том, что управление пакетами на целевой платформе во время работы с удаленного хранилища пакетов выполняется другим инструментом с иным набором команд. При наличии сценариев, вызывавших инструмент напрямую или через API, их нужно изменить. Информация о менеджере DNF доступна по ссылке.
Rpm 5.x заменен на Rpm 4.x по двум основным причинам:

- DNF не совместим на уровне API с 5.x, а перенос и поддержка являются сложными задачами;
- Rpm 5.x имеет ограниченную поддержку и YP является одним из немногих применений.

Поддержка Berkeley DB 6.x удалена и по умолчанию используется Berkeley DB 5.x.

- Версия 6.x Berkeley DB была отвергнута значительной частью сообщества по причине лицензии AGPLv3. В результате большинство проектов с открытым кодом, использующих DB, продолжает работать с DB 5.x.
- В OE-core использование DB 6.x нужно было лишь Rpm 5.x и нет причин сохранять DB 6.x в OE-core.

Инструментcreaterepo заменен createrepo_c, который является современным средством генерации метаданных удаленного репозитория и работает быстрее, чем createrepo(язык c вместоPython).
Независимые от архитектуры пакеты RPM теперь используют суффикс noarch вместо all.

Это обусловлено тем, во многих случаях использования DNF/RPM4 такой переход уже произошел. Меняются лишь имена файлов и теги архитектуры. Никаких иных изменений не вносится в OE-core и класс allarch.bbclass.
Подписание удаленных хранилищ пакетов с помощью PACKAGE_FEED_SIGN не поддерживается. Проблема будет полностью решена в новом выпуске YP (см. defect 11209 ).
OPKG сейчас использует по умолчанию библиотеку libsolv для учета зависимостей пакетов, что значительно превосходит использовавшийся ранее внутренний инструмент OPKG. Изменение ведет к незначительному росту размера на диске (около 500 кбайт) и расхода оперативной памяти (см. commit message).

4.11.9. Удаленные задания

linux-yocto 4.8 – версия 4.8 удалена, версии 4.1 (LTSI), 4.4 (LTS), 4.9 (LTS/LTSI) и 4.10 сохранены.
python-smartpm – функционально заменено dnf.
createrepo – заменено createrepo-c.
rpmresolve – больше не требуется в результате перехода на RPM 4 по причине использования самого RPM.
gstreamer – удалены задания GStreamer Git, поскольку они устарели. Задания 1.10.x сохранены.
alsa-conf-base – объединено с alsa-conf, поскольку libasound зависит от обоих.
tremor – перенесено в meta-multimedia. Целочисленное декодирование Vorbis не требуется современному оборудованию. Поэтому подключаемый модуль GStreamer ivorbis по умолчанию отключен, что избавляет от необходимости включать задание tremor в OE-Core.
gummiboot – заменено systemd-boot.

4.11.10. Изменения Wic

Используемый по умолчанию выходной каталог. Сейчас Wic использует текущий каталог, а не /var/tmp/wic. Опции -o и –outdir сохранились и служат для задания предпочтительного выходного каталога.
Удален подключаемый модуль fsimage. Плагин Wic fsimage дублировал функциональность rawcopy.

Описание Wic доступно в разделе Creating Partitioned Images Using Wic [2].

4.11.11. Изменения QA

Проверкаunsafe-references-in-binaries, отключенная по умолчанию, была удалена. Эта проверка была предназначена для обнаружения двоичных файлов в каталоге /bin,связанных с библиотеками в/usr/lib для случая наличия у пользователя каталога /usr на отдельной от /файловой системе.

Удаленная проверка имела ошибки. Каталог /usr сейчас редко размещается в разделе отдельном от /.
Проверкаfile-rdeps сейчас по умолчанию возвращает ошибку, а не предупреждение. Поэтому требуется решить проблемы с невыполненными зависимостями. Дополнительная информация приведена в параграфах 6.56. insane.bbclass и 10.2. Ошибки и предупреждения.

4.11.12. Прочие изменения

В этом выпуске изменено множество заданий для игнорирования элемента largefile в DISTRO_FEATURES, включающего безусловную поддержку больших файлов. Свойство всегда было включено по умолчанию, а его отключение не тестировалось достаточно широко. В будущих выпусках YP возможность отключения свойства поддержки больших файлов будет упразднена совсем.
Если значение DISTRO_VERSION включает значение переменной DATE, которое принято по умолчанию для выпусков Poky, значение DATE явно исключается из /etc/issue и /etc/issue.net, которые выводятся в приглашении на регистрацию в системе, чтобы избежать конфликтов при использовании нескольких библиотек (Multilib). В любом случае значение DATE не является точным, если задание base-files восстановлено из общего состояния (sstate), а не собрано заново.

Если нужно записать дату сборки в /etc/issue* или иное место образа, лучше всего задать для этого функцию пост-обработки и вызвать ее из команды ROOTFS_POSTPROCESS_COMMAND. Это обеспечит соответствие значения моменту создания образа.
Сценарий инициализации Dropbear сейчас по умолчанию запрещает DSA-ключи хоста. Это изменение соответствует файлу службы systemd, который поддерживает только ключи RSA, и свежим версиям OpenSSH, где не поддерживаются ключи DSA для хоста.
Класс buildhistory сейчас корректно использует символы табуляции в качестве разделителей колонок в файле installed-package-sizes.txt,что позволяет импортировать этот файл.
Переменная USE_LDCONFIG заменена свойствомldconfig в переменной DISTRO_FEATURES. Дистрибутивам, которые раньше задавали USE_LDCONFIG = “0”, следует вместо этого указывать DISTRO_FEATURES_BACKFILL_CONSIDERED_append = ” ldconfig”.
Принятое по умолчанию значение COPYLEFT_LICENSE_INCLUDE сейчас включает все версии лицензий AGPL в дополнение к GPL и LGPL. Заданный по умолчанию список не гарантирует полноты и следует обратиться к юридическим документам с учетом дистрибутива, если нет полной уверенности.
Пакеты модулей ядра сейчас имеют суффиксы с номером версии для возможности сосуществования на целевой системе нескольких версий ядра. Для возврата к прежней схеме именования без суффиксов следует указать KERNEL_MODULE_PACKAGE_SUFFIX = “”.
Удаление файлов libtool *.la сейчас включено по умолчанию, поскольку эти файлы реально не нужны в Linux и их перемещение создает дополнительную нагрузку. Если нужно сохранить такие файлы, следует изменить переменную INHERIT_DISTRO,чтобы она не включала значение “remove-libtool”.
Расширяемые SDK, собранные для GCC 5+, сейчас отвергают установку в дистрибутивы с версиями GCC на хосте 4.8 или 4.9. Это изменение вызвано тем, что известно об отказе при инсталляции из-за способа сборки общего состояния uninative (sstate). Дополнительные сведения приведены в параграфе 6.140. uninative.bbclass.
Все естественные и nativesdk задания теперь используют раздельные значения DISTRO_FEATURES вместо общего для заданий платформы, чтобы избежать неоправданной повторной сборки. В качестве DISTRO_FEATURES для естественных заданий служит DISTRO_FEATURES_NATIVE,добавленная к пересечению переменныхDISTRO_FEATURES и DISTRO_FEATURES_FILTER_NATIVE. Для заданий nativesdk соответствующими переменными являются DISTRO_FEATURES_NATIVESDK и DISTRO_FEATURES_FILTER_NATIVESDK.
Переменная FILESDIR, которая ранее была отменена и применялась редко, сейчас удалена совсем. Следует заменить в заданиях эту переменную на FILESPATH.
Переменная MULTIMACH_HOST_SYS удалена, поскольку уже не нужна для связанных с заданиями sysroot.

4.12. Переход на YP 2.4

В этом разделе рассмотрен переход на YP 2.4 с предыдущего выпуска.

4.12.1. Режим присутствия в памяти

Постоянный режим теперь доступен в принятой по умолчанию работе BitBake вместо прежнего резидентного режима (memory resident mode, т. е. oe-init-build-env-memres). Сейчас нужно лишь установить тайм-аут в переменной BB_SERVER_TIMEOUT (секунды) и сервер BitBake будет оставаться в памяти заданное время между вызовами. Сценарий oe-init-build-env-memres удален за ненадобностью.

4.12.2. Изменения в пакетах

python3

- Основной пакет python3 теперь содержит весь стандартный дистрибутив Python 3. Это соответствует поведению, ожидаемому в традиционных дистрибутивах Linux. Если нужно установить лишь часть Python 3, указывается python-core и один или несколько отдельных пакетов, которые нужны.
- python3 – сценарии bz2.py, lzma.py, и _compression.py перенесены из python3-misc в python3-compression.

binutils – библиотека libbfd помещена в отдельный пакет libbfd, что экономит пространство при установке некоторых инструментов (например, perf), когда нужна лишь библиотека libbfd а не весь пакет binutils.
util-linux

- Программа su помещена в отдельный пакет util-linux-su, который собирается только при наличии pam в переменной DISTRO_FEATURES. Пакет util-linux should не следует устанавливать, пока он не требуется, поскольку su обычно предоставляется через файл shadow. Основной пакет util-linux зависит при работе (RDEPENDS) от util-linux-su, если pam присутствует в DISTRO_FEATURES.
- Программа switch_root program помещена в отдельный пакет util-linux-switch-root для небольших образов initramfs, которым не нужен весь пакет util-linux или исполняемый файл busybox, которые значительно больше switch_root. В основном пакете util-linux имеется рекомендуемая зависимость (RRECOMMENDS) от пакета util-linux-switch-root.
- Программа ionice помещена в отдельный пакет util-linux-ionice. В основном пакете util-linux имеется рекомендуемая зависимость (RRECOMMENDS) от пакета util-linux-ionice.

initscripts - программа sushell помещена в отдельный пакет initscripts-sushell, что позволяет системам получать sushell при включенном selinux. Это избавляет от необходимости устанавливать весь пакет initscripts. Основной пакет initscripts зависит при работе (RDEPENDS) от sushell, если selinux присутствует в DISTRO_FEATURES.
glib-2.0 сейчас имеет рекомендованную зависимость (RRECOMMENDS) от пакета shared-mime-info, поскольку значительная часть GIO бесполезна при отсутствии базы данных MIME. Можно исключить зависимость через переменную BAD_RECOMMENDATIONS, если пакет shared-mime-info слишком велик и не требуется.
Стандартный запуск Go. Стандартная среда запуска Go выделена из основного задания go в go-runtime.

4.12.3. Удаленные задания

acpitests не поддерживается.
autogen-native больше не требуется для Grub, oe-core, meta-oe.
bdwgc уже не требуется в OpenEmbedded-Core и перенесено в meta-oe.
byacc нужно лишь для rpm 5.x и перенесено в meta-oe.
gcc (5.4) – версия 5.4 не поддерживается с заменой на 6.3/7.2.
gnome-common не поддерживается и больше не требуется.
go-bootstrap-native – Go 1.9 выполняет загрузку самостоятельно, поэтому задание удалено.
guile требовалось только в autogen-native и remake, а теперь не нужно этим программам.
libclass-isa-perl ранее требовалось для LSB 4, а сейчас не нужно.
libdumpvalue-perl ранее требовалось для LSB 4, а сейчас не нужно.
libenv-perl ранее требовалось для LSB 4, а сейчас не нужно.
libfile-checktree-perl ранее требовалось для LSB 4, а сейчас не нужно.
libi18n-collate-perl ранее требовалось для LSB 4, а сейчас не нужно.
libiconv требовалось только для uclibc, удаленной в предыдущем выпуске. Библиотеки glibc и musl имеют свои реализации, meta-mingw требуется для libiconv, поэтому перенесено в meta-mingw.
libpng12 ранее требовалось для LSB. Сейчас применяется libpng 1.6.x.
libpod-plainer-perl ранее требовалось для LSB 4, а сейчас не нужно.
linux-yocto (4.1) удалено с заменой на 4.4, 4.9, 4.10, 4.12.
mailx ранее требовалось для совместимости с LSB, разработка прекращена.
mesa (только версия git) – git-версия задания устарела по сравнению с версией выпуска.
ofono (только версия git) – git-версия задания устарела по сравнению с версией выпуска.
portmap устарело и заменено rpcbind.
python3-pygpgme устарело и не поддерживается. Ранее требовалось для пакета dnf, который переключен сейчас на gpgme Python.
python-async удалено с переносом на Python 3.
python-gitdb удалено с переносом на Python 3.
python-git удалено с переносом на Python 3.
python-mako удалено с переносом на Python 3.
python-pexpect удалено с переносом на Python 3.
python-ptyprocess удалено с переносом на Python 3.
python-pycurl не применяется в OpenEmbedded-Core (meta-oe).
python-six удалено с переносом на Python 3.
python-smmap удалено с переносом на Python 3.
remake в качестве провайдера virtual/make больше не применяется, поэтому не нужно в OpenEmbedded-Core.

4.12.4. Перенос дерева устройств ядра

Поддержку дерева устройств ядра сейчас проще включить в задании для ядра, поскольку код дерева устройств перенесен в класс kernel-devicetree. Функциональность включается автоматически для любого задания, наследующего класс kernel и установившего переменную KERNEL_DEVICETREE. Прежний механизм с файлом meta/recipes-kernel/linux/linux-dtb.incпродолжает работать, но вызывает предупреждения. В будущих выпусках YP файл meta/recipes-kernel/linux/linux-dtb.incпредполагается удалить. Рекомендуется исключить все обязательные операторы, запрашивающие meta/recipes-kernel/linux/linux-dtb.inc, из заданий для ядер.

4.12.5. Изменения QA для пакетов

Проверка unsafe-references-in-scripts удалена.
При указании ${COREBASE}/LICENSE в LIC_FILES_CHKSUM выдается предупреждение, поскольку файл является описанием лицензии для OE-Core. Следует применять ${COMMON_LICENSE_DIR}/MIT,если задание использует лицензиюMIT и нет возможности задать предпочтительный метод указания файла в дереве кода.

4.12.6. Изменения в файлах `README`

Основной файл Poky README перенесен на уровень meta-poky и переименован в README.poky. Для прежнего местоположения создана символьная ссылка.
Файл README.hardware перенесен на уровень meta-yocto-bsp с символьной ссылкой на прежнее место.
Создан файл README.qemu для машин qemu*.

4.12.7. Прочие изменения

Удалена переменная ROOTFS_PKGMANAGE_BOOTSTRAP и все ссылки на нее, поэтому следует исключить переменную из своих заданий.
Удален каталог meta-yocto. В выпуске YP 2.1 уровень meta-yocto был переименован в meta-poky, а подкаталог meta-yocto сохранили для предотвращения проблем в имеющихся конфигурациях.
Файл maintainers.inc, который указывал сопровождающих путем указания ответственного за каждое задание в OE-Core, перенесен из meta-poky в OE-Core (из meta-poky/conf/distro/include в meta/conf/distro/include).
Класс buildhistory делает одну фиксацию (commit) на сборку, а не на подкаталог репозитория. Это предполагает, что фиксация разрешена (BUILDHISTORY_COMMIT = “1”), что является обычным делом. Ранее класс buildhistory делал фиксацию на подкаталог репозитория для упрощения просмотра изменений в каталоге. Сейчас для просмотра таких изменений следует указывать каталог в качестве последнего параметра команды git show или git diff.
Файл x86-base.inc, включаемый во все конфигурации машин x86, устанавливает IMAGE_FSTYPES ?= “live”, вместо использования оператора +=. Это упрощает переопределение принятого по умолчанию значения.
BitBake выдает множество событий BuildStarted при включенном множестве конфигураций (одно событие на конфигурацию). Дополнительная информация приведена в разделе Events [4].
По умолчанию файл security_flags.inc устанавливает переменную GCCPIE с опцией включения PIE11 в gcc, что осложняет организацию атак ROP¹².
OE-Core предоставляет подключаемый модуль bitbake-layers с командой create-layer, реализация которой привела к ненужности сценария yocto-layer, который
может быть удален из будущих выпусков YP.
Типы vmdk, vdi, qcow2 для файлов образов сейчас применяются вместе с типом образа wic через переменную CONVERSION_CMD. Эквивалентные типы образов имеют значения wic.vmdk, wic.vdi и wic.qcow2.
do_image_<type>[depends] было заменено переменной IMAGE_DEPENDS_<type>. При наличии классов с пользовательскими типами образов их следует обновить.
Добавлена поддержка OpenSSL 1.1, однако 1.0.x продолжает по умолчанию использоваться в переменной PREFERRED_VERSION. Это сохранено из-за остающихся проблем совместимости с другими программами. Переменная PROVIDES в задании openssl 1.0 сейчас включает openssl10 как маркер, который может использоваться DEPENDS в заданиях, собирающих программы, зависимые от OpenSSL 1.0.
Для согласованного поведения опций BitBake -r и -R (prefile и postfile), используемых для чтения или пост-чтения дополнительного конфигурационного файла из командной строки, они сейчас действуют лишь в текущей команде BitBake command. раньше указанные опции BitBake сохранялись при следующих вызовах.

4.13. Переход на YP 2.5

В этом разделе рассмотрен переход на YP 2.5 с предыдущего выпуска.

4.13.1. Изменения в пакетах

bind-libs – библиотеки подготавливаются заданием bind в отдельном пакете bind-libs.
libfm-gtk – привязки libfm GTK+ перенесены в отдельный пакет libfm-gtk.
flex-libfl – задание flex выделено из libfl в пакет flex-libfl для снижения числа зависимостей при установке только библиотеки.
grub-efi – конфигурация grub-efi перенесена в отдельное задание grub-bootconf. Однако зависимость от grub-efi указывается через провайдера virtual/grub-bootconf, что позволяет иметь свое задание для обеспечения зависимости. Можно использовать файл добавления BitBake для возврата конфигурации в задание grub-efi.
Поддержка устаревших хранилищ пакетов armv7a удалена для перехода с armv7a на armv7a-vfp-neon в хранилищах пакетов, который раньше включался переменной PKGARCHCOMPAT_ARMV7A. Переход произошел в 2011 г. и активные хранилища пакетов должны быть обновлены с указанием новых имен.

4.13.2. Удаленные задания

gcc – версия 6.4 заменена 7.x.
gst-player переименовано в gst-examples.
hostap-utils – пакет устарел.
latencytop больше не поддерживается (последний выпуск был в 2009 г.).
libpfm4 требовалось лишь удаленному заданию oprofile.
linux-yocto – версии 4.4, 4.9, 4.10 удалены, версии 4.12, 4.14, 4.15 сохраняются.
man заменено современным man-db
mkelfimage – программа удалена из проекта coreboot и больше не нужна после удаления типа образов ELF.
nativesdk-postinst-intercept не поддерживается.
neon – программа не поддерживается и больше не нужна в OpenEmbedded-Core.
oprofile – функциональность заменена perf, а совместимость с musl может быть затруднена.
pax – программа устарела.
stat – программа не развивается, а функции stat обеспечивает пакет coreutils.
zisofs-tools-native больше не требуется после исключения сжатых образов ISO.

4.13.3. Изменения сценариев и инструментов

yocto-bsp, yocto-kernel, yocto-layer, ранее входившие в poky, но не в OpenEmbedded-Core, удалены. Эти сценарии устарели и не поддерживаются, что во многих случаях ограничивало их применимость. Команда bitbake-layers create-layer служит их прямой заменой для yocto-layer(см. раздел BSP Kernel Recipe Example [6]).
devtool finish сейчас завершает работу с ошибкой при наличии непредставленных изменений или в процессе выполнения rebase в репозитории задания. Причиной ошибки могут быть незафиксированные изменения, не включенные в обновления к исправлениям, которые применены заданием. Если эти изменения несущественны, можно форсировать выполнение команды с помощью опции -f или –force.
scripts/oe-setup-rpmrepo – функциональность заменена командой bitbake package-index.
scripts/test-dependencies.sh – устарел и заменен функциональностью sysroots для заданий, добавленной YP 2.4.

4.13.4. BitBake

Изменена опция --runall, которая имеет 2 варианта поведения:

- вариант A – для данной цели (набора целей) просматривается граф задач и задача X запускается лишь при ее наличии и включении в сборку.
- вариант B – для данной цели (набора целей) просматривается граф задач и задача X запускается, если любое задание в графе задач имеет такую цель, даже если этого задания нет в исходном графе задач.

Опция --runall сейчас работает по варианту B, а ранее работала подобно варианту A. Опция --runonly добавлена для сохранения возможности использовать вариант A.

Удалены несколько явных задач, выполнявшихся для всех заданий в дереве зависимостей (например, fetchall, checkuriallи все задачи классовdistrodata и archiver). Имеется опция BitBake, позволяющая выполнить это для любой задачи. Например, bitbake <target> -c fetchall следует заменить на bitbake <target> –runall=fetch.

4.13.5. Изменения Python и Python 3

Управляемые сценариями файлы python-*-manifest.inc,применявшиеся для генерации пакетовPython и Python 3, заменены файлом JSON для удобства чтения и поддержки. Доступна новая задача для сопровождающих задания Python, которая переключает на файл JSON при переходе на новые версии Python. Файл можно редактировать напрямую вместо редактирования сценария и использования его для обновления файла.

Еще одно изменение, которое следует отметить, связано с тем, что задания Python больше не имеют провайдеров во время сборки пакетов. Это предполагает, что python является одним из пакетов, обеспечиваемых заданием Python. Можно больше не запускать bitbake python-foo и не иметь DEPENDS для python-foo, но нужно добавить IMAGE_INSTALL_append = ” python-foo” или RDEPENDS_${PN} = “python-foo”.

Поведение прежних провайдеров при сборке было причудой способа создания манифестов Python. Более подробные сведения об изменениях доступны по ссылке.

4.13.6. Прочие изменения

Класс kernel поддерживает сборку пакетов для нескольких ядер. Если задание для ядра или файл .bbappend включает упаковку, следует заменить ссылку на ядро в именах пакетов значением ${KERNEL_PACKAGE_NAME}. Например, при запрете автоматической установки ядра с помощью RDEPENDS_kernel-base
= “” можно избежать предупреждений, задав RDEPENDS_${KERNEL_PACKAGE_NAME}-base= “”.
Класс buildhistory по умолчанию фиксирует изменения в репозитории и больше не нужно задавать BUILDHISTORY_COMMIT = “1”. Если нужно отключить фиксацию, установите BUILDHISTORY_COMMIT = “0”.
Эталонная машина beaglebone переименована в beaglebone-yocto. BSP beaglebone-yocto является эталонной реализацией, использующей лишь компоненты OpenEmbedded-Core и meta-yocto-bsp, тогда как Texas Instruments поддерживает полнофункциональный BSP на уровне meta-ti. Переименование избавило от имевшегося конфликта имен двух BSP.
Класс update-alternatives больше не работает со сценариями инициализации SysV, поскольку это стало проблематичным. Задание sysklogd больше не применяет update-alternatives по причине несовместимости с другими реализациями.
По умолчанию класс cmake использует при сборке пакетов ninja вместо makeдля повышения производительности сборки. Если задание не работает с ninja, можно установить OECMAKE_GENERATOR = "Unix Makefiles" для возврата к make.
Ранее отмененные функции base_* удалены с заменами из meta/lib/oe и bitbake/lib/bb. Эти функции обычно использовались в заданиях и классах и все ссылки на удаленные функции следует изменить в соответствии с приведенной ниже таблицей.

Удалено	Замена
base_path_join()	oe.path.join()
base_path_relative()	oe.path.relative()
base_path_out()	oe.path.format_display()
base_read_file()	oe.utils.read_file()
base_ifelse()	oe.utils.ifelse()
base_conditional()	oe.utils.conditional()
base_less_or_equal()	oe.utils.less_or_equal()
base_version_less_or_equal()	oe.utils.version_less_or_equal()
base_contains()	bb.utils.contains()
base_both_contain()	oe.utils.both_contain()
base_prune_suffix()	oe.utils.prune_suffix()
oe_filter()	oe.utils.str_filter()
oe_filter_out()	oe.utils.str_filter_out() (или оператор _remove).

Использование exit 1 для явной отсрочки сценария пост-установки до первой перезагрузки отменено, поскольку этот неочевидный механизм может скрывать ошибки. Если во время создания rootfsнужно явно отложить пост-установку до первой перезагрузки, следует использовать pkg_postinst_ontarget() или вызов postinst-intercepts defer_to_first_boot from pkg_postinst(). Любой отказ сценария pkg_postinst(),включая exit 1,будет вызывать предупреждение при работе задачиdo_rootfs.

Дополнительная информация приведена в разделе Post-Installation Scripts [2].
Образы типа elf исключены, поскольку инструмент mkelfimage,который нужен для их создания, больше не поддерживается вcoreboot и требует обновления при каждом изменении binutils.
Удалена поддержка сжатия образов .iso (ранее включаемая через COMPRESSISO = "1"). Инструменты пользовательского пространства (zisofs-tools) не поддерживаются, а squashfs обеспечивает более эффективное сжатие. Для сборки live-образов с компрессией squashfs+lz4 следует задать LIVE_ROOTFS_TYPE = "squashfs-lz4" и включить live в IMAGE_FSTYPES.
Заданием с безусловной зависимостью от libpam было лишь buildable с pam в DISTRO_FEATURES. Если зависимость не является обязательной, лучше сделать ее условной по наличию pam в DISTRO_FEATURES.
Для машин на базе EFI загрузчик (по умолчанию grub-efi) устанавливается в образе как /boot. Можно использовать Wic для разделения загрузчика на разделы boot и rootfs.
Patch-файлы, контекст которых не имеет точного соответствия (исправление дает fuzz при наложении), будут вызывать предупреждения. Пример доступен по ссылке.
Предполагается, что уровни устанавливают LAYERSERIES_COMPAT_layername в соответствии с версией OpenEmbedded-Core, с которой они совместимы. Это указывается как кодовое имя с использованием пробелов для разделения значений (например, “rocko sumo”). Если уровень не устанавливает LAYERSERIES_COMPAT_layername, выводится предупреждение. Если уровень устанавливает значение, не включающее текущей версии (“sumo” для выпуска 2.5), выдается ошибка.
В переменной окружения TZ устанавливается значение UTC в среде сборки для предотвращения проблем воспроизводимости в некоторых заданиях.

4.14. Переход на YP 2.6

В этом разделе рассмотрен переход на YP 2.6 с предыдущего выпуска.

4.14.1. По умолчанию применяется GCC 8.2

GNU Compiler Collection версии 8.2 сейчас по умолчанию используется для компиляции. Дополнительная информация об изменениях в выпуске GCC 8.x доступна по ссылке https://gcc.gnu.org/gcc-8/changes.html. Для случаев потребности в компиляторе версии 7.x сохранен GCC 7.3. Этот компилятор можно выбрать, установив в конфигурации для переменной GCCVERSION значение “7.%”.

4.14.2. Удаленные задания

beecrypt не требуется в связи с переходом на RPM 4.
bigreqsproto заменено xorgproto.
calibrateproto удалено с заменой на xinput.
compositeproto, damageproto, dmxproto, dri2proto, dri3proto заменены xorgproto.
eee-acpi-scripts устарело.
fixesproto, fontsproto заменены xorgproto.
fstests устарело.
gccmakedep больше не применяется.
glproto заменено xorgproto.
gnome-desktop3 больше нет требуется. Перенесено в meta-oe.
icon-naming-utils больше не применяется в результате удаления темы Sato в 2016 г.
inputproto, kbproto заменены xorgproto.
libusb-compat устарело.
libuser устарело.
libnfsidmap больше не требуется с переходом на nfs-utils 2.2.1.
libxcalibrate больше не требуется.
mktemp устарело. Команда mktemp предоставляется заданиями busybox и coreutils.
ossp-uuid не будет поддерживаться и в основном заменено uuid.h в util-linux.
pax-utils больше не нужно. Прежние тесты QA использовали это задание при сборке.
pcmciautils устарело.
pixz больше не требуется, поскольку xz поддерживает многопотоковое сжатие.
presentproto, randrproto, recordproto, renderproto, resourceproto, scrnsaverproto заменены xorgproto.
trace-cmd устарело, функциональность заменена perf.
wireless-tools устарело и заменено iw.
xcmiscprotoзамененоxorgproto.
xextproto заменено xorgproto.
xf86dgaproto заменено xorgproto.
xf86driproto заменено xorgproto.
xf86miscproto заменено xorgproto.
xf86-video-omapfb устарело, взамен используется драйвер ядра modesetting.
xf86-video-omap устарело, взамен используется драйвер ядра modesetting.
xf86vidmodeproto заменено xorgproto.
xineramaproto заменено xorgproto.
xproto заменено xorgproto.
yasm больше не требуется, поскольку прежнее использование заменено nasm.

4.14.3. Изменения в пакетах

cmake – файлы cmake.m4 и инструментарий перенесены в основной пакет.
iptables – модули размещены в отдельных пакетах.
alsa-lib – библиотека libasound перенесена в основной пакет alsa-lib из libasound.
glibc – libnss-db теперь в своем пакете вместе со сценарием /var/db/makedbs.sh для обновления баз данных.
python и python3 – основной пакет удален из задания. Нужно установить конкретные пакеты python-modules или python3-modules для остального.
systemtap – systemtap-exporter перемещен в отдельный пакет.

4.14.4. Зависимости протокола XOrg

Находящиеся в разработке репозитории *proto объединены в xorgproto, поэтому соответствующие задания также были объединены в xorgproto. Задания, зависимые от старых заданий *proto,следует исправить с заменой наxorgproto. Имена удаленных при объединении заданий приведены в параграфе 4.14.2. Удаленные задания.

4.14.5. Предотвращение зависимости сборщиков в `do_configure`

Ранее для заданий Python, наследующих классы distutils и distutils3,при выполнении задачиdo_configure можно было выполнить зависимости, заданные в setup.py,если они не были указаны в sysroot (т. е. задания, указывающие зависимости не были включены в DEPENDS).

Это изменение влияет не только на упомянутые классы distutils и distutils3,но и на все задания, наследующие distutils*, например, на задания setuptools и setuptools3.

Извлечение типов зависимостей, не указанных в sysroot, снижает производительность сборки, поэтому такая выборка была явно отключена. В результате все отсутствующие в заданиях Python зависимости при использовании этих классов будут давать ошибку в задаче do_configure.

4.14.6. Решена проблема настройки аудита в `linux-yocto`

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

4.14.7. Именование элементов образов и ядер

Имена переменных (например, IMAGE_NAME) используют новую переменную IMAGE_VERSION_SUFFIXвместо DATETIME,что упрощает изменения. Переменная IMAGE_VERSION_SUFFIX задается файлом bitbake.conf в форме IMAGE_VERSION_SUFFIX = “-${DATETIME}”.

Имена некоторых переменных изменены для согласованности, как показано в таблице.

Старое имя	Новое имя
KERNEL_IMAGE_BASE_NAME	KERNEL_IMAGE_NAME
KERNEL_IMAGE_SYMLINK_NAME	KERNEL_IMAGE_LINK_NAME
MODULE_TARBALL_BASE_NAME	MODULE_TARBALL_NAME
MODULE_TARBALL_SYMLINK_NAME	MODULE_TARBALL_LINK_NAME
INITRAMFS_BASE_NAME	INITRAMFS_NAME

Переменная MODULE_IMAGE_BASE_NAME удалена, имя архива контролируется напрямую переменной MODULE_TARBALL_NAME.
Переменные KERNEL_DTB_NAME и KERNEL_DTB_LINK_NAME добавлены для управления элементами дерева устройств ядра (DTB¹³) вместо переменных KERNEL_IMAGE_*.
Добавлены переменные KERNEL_FIT_NAME и KERNEL_FIT_LINK_NAME для задания имени плоского дерева образа (FIT¹⁴) для образов ядра подобно другим развернутым элементам.
Значения переменных MODULE_TARBALL_NAME и MODULE_TARBALL_LINK_NAME больше не включают префиксов module- и суффиксов .tgz. Эти части сейчас кодируются жестко для согласованности и другими переменными именования элементов.
Добавлена переменная INITRAMFS_LINK_NAME для контроля символьных ссылок подобно другим элементам.
INITRAMFS_NAME сейчас использует ${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX} вместо ${PV}-${PR}-${MACHINE}-${DATETIME} для соответствия другим переменным.

4.14.8. Отмена `SERIAL_CONSOLE`

Переменная SERIAL_CONSOLE функционально заменена переменной SERIAL_CONSOLES некоторое время назад. С выпуска YP 2.6 переменная SERIAL_CONSOLE отменена официально. SERIAL_CONSOLE будет работать как в прежних выпусках, но для совместимости с новыми версиями рекомендуется заменить ее на SERIAL_CONSOLES. Различия между этими переменными заключается в том, что в SERIAL_CONSOLES элементы записи разделяются точкой с запятой вместо пробела, а также возможно указание нескольких консолей, разделенных пробелами.

4.14.9. Сценарий настройки считает неизвестные опции ошибкой

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

4.14.10. Изменение переопределений

Удалены virtclass-native и virtclass-nativesdk, отмененные в 2012 г. с заменой на class-native и class-nativesdk. Переопределения virtclass-multilib- для multilib сохраняются.
Более высокий приоритет forcevariable по сравнению с libc был документирован достаточно давно, однако давняя причуда с установкой OVERRIDES давала переопределениям libc (например libc-glibc, libc-musl и т. п.) более высокий приоритет. Сейчас это устранено.

Это изменение не должно вызывать проблем, однако в некоторых необычных конфигурациях возможно иное поведение, нежели предполагалось ранее. Нужно проверить переопределения forcevariable и libc-* на пользовательских уровнях в части их осмысленности.
Удалено build-${BUILD_OS}, которое обычно имело форму build-linux, поскольку сборка в ОС хоста, отличной от последней версии Linux не поддерживается и не рекомендуется. Отказ от переопределения позволяет избежать ложного впечатления о поддержке других версий операционной системы.
Оператор _remove сохраняет пробелы, поэтому при указании списка удаляемых элементов следует помнить, что пробелы в начала и в конце не удаляются (см. примеры в разделе Removal (Override Style Syntax) [4]).

4.14.11. Конфигурация `systemd` выделена в `systemd-conf`

Конфигурация задания systemd перенесена в system-conf, что позволяет избавить systemd от машинозависимости при необходимости применить зависимую от машину конфигурацию (например, для машин qemu*). Задание включает:

     ${sysconfdir}/machine-id
     ${sysconfdir}/systemd/coredump.conf
     ${sysconfdir}/systemd/journald.conf
     ${sysconfdir}/systemd/logind.conf
     ${sysconfdir}/systemd/system.conf
     ${sysconfdir}/systemd/user.conf

Если ранее применялись файлы bbappend для добавления systemd с целью изменить какой-то из приведенных выше файлов, сейчас это нужно делать в задании systemd-conf.

4.14.12. Изменение автоматического тестирования

Удалена переменнаяTEST_IMAGE, которая при установке значения 1 включала автоматическое тестирование сборки образа. Сейчас вместо этого используется значение переменной TESTIMAGE_AUTO.
Наследование классов testimage и testsdk. Опыт диктует использование переменной IMAGE_CLASSES,а неINHERIT при наследовании классов testimage и testsdk для автоматического тестирования.

4.14.13. Изменение OpenSSL

Пакет OpenSSL обновлен с версии 1.0 до 1.1. Обновление может создать проблемы для заданий, использующих обе версии в своих цепочках зависимостей, поскольку обе версии не могут быть установлены одновременно при сборке.

При работе могут применяться обе версии библиотеки.

4.14.14.Изменение BitBake

Журнальный файл сервера bitbake-cookerdaemon.log всегда присутствует в каталоге сборки, а не в текущем каталоге.

4.14.15. Изменение защиты

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

4.14.16. Изменение пост-установки

Нужно явно указать задержку пост-установки до целевой платформы. Если нужно явно отложить пост-установку на целевой платформе до перезагрузки после инсталляции, следует использовать pkg_postinst_ontarget() или вызов postinst-intercepts defer_to_first_boot из pkg_postinst(). Любой отказ сценария pkg_postinst(), включая exit 1, будет вызывать ошибку задачи do_rootfs. Информация о пост-установке приведена в разделе Post-Installation Scripts [2].

4.14.17. Оптимизация на основе профилей Python 3

Задание python3 сейчас включает оптимизацию по профилю, что несколько увеличивает время сборки для повышения производительности работы на целевой платформе. Оптимизация включается лишь при поддержке текущей машиной MACHINE пользовательского режима эмуляции в QEMU (“qemu-usermode” присутствует в MACHINE_FEATURES, как принято по умолчанию).

Если нужно отключить оптимизацию для любого значения MACHINE_FEATURES, следует убедиться в отсутствии pgo в переменной PACKAGECONFIG для задания python3. Это можно сделать, указав на уровне конфигурации PACKAGECONFIG_remove_pn-python3 = “pgo” или задав PACKAGECONFIG в файле добавления для python3.

4.14.18. Прочие изменения

По умолчанию используется набор инструкций Thumb-2 для armv7a и выше. При наличии заданий для сборки программ, которым нужен набор инструкций ARM, его можно задать в виде ARM_INSTRUCTION_SET = “arm”.
run-postinsts больше не использует /etc/*-postinsts для dpkg/opkg, применяя
встроенную поддержку пост-установки. Поведение RPM не изменилось.
Переменные NOISO и NOHDD больше не применяются. Можно управлять сборкой образов *.iso и *.hddimg напрямую через переменную IMAGE_FSTYPES.
От сценария scripts/contrib/mkefidisk.sh отказались в пользу Wic.
Задание kernel-modules удалено из RRECOMMENDS для машин qemumips и qemumips64. Исключено также влияние файла x86-base.inc. Для машин genericx86 и genericx86-64 задание kernel-modules сохранено в переменной RRECOMMENDS.
Удалена переменная LGPLv2_WHITELIST_GPL-3.0.При наличии ее в конфигурации следует вместо нее установить или дополнить переменнуюWHITELIST_GPL-3.0.
${ASNEEDED} сейчас напрямую включается в переменную TARGET_LDFLAGS. Другие определения из meta/conf/distro/include/as-needed.inc перенесены в соответствующие задания.
Поддержка ключей DSA для хоста исключена из заданий OpenSSH. Если такие ключи продолжают использоваться, следует перейти на более защищенные алгоритмы, рекомендуемые OpenSSH.
Задание dhcp сейчас применяет конфигурационный файл dhcpd6.conf в dhcpd6.service для IPv6 DHCP вместо файла dhcpd.conf, который сейчас служит для IPv4.

4.15. Переход на YP 2.7

В этом разделе рассмотрен переход на YP 2.7 с предыдущего выпуска.

4.15.1. BitBake

BitBake проверяет анонимные (anonymous) и чистые (pure) функции Python (например, def funcname:) в метаданных на предмет использования символов табуляции с выдачей предупреждений при их наличии.
Bitbake проверяет BBFILE_COLLECTIONS на предмет дубликатов с возвратом ошибки при обнаружении.

4.15.2. Исключена поддержка Eclipse™

Поддержка Eclipse IDE исключена, но сохраняется для выпусков до 2.7. Выпуск 2.7 не включает плагин Eclipse Yocto.

4.15.3. Разделение системной и пользовательской части в `qemu-native`

Системная и пользовательская часть задания qemu-native разделены. Задание qemu-native обеспечивает пользовательские компоненты, а qemu-system-native – системные. При наличии заданий, зависящих от функциональности системы эмуляции QEMU при сборке, следует заменить в них qemu-native на qemu-system-native.

4.15.4. Удаление файла `upstream-tracking.inc`

Ранее отмененный файл upstream-tracking.inc удален. Все переменные UPSTREAM_TRACKING* устанавливаются в соответствующих заданиях. Следует удалить в своей конфигурации все ссылки на файл upstream-tracking.inc.

4.15.5. Удаление переменной `DISTRO_FEATURES_LIBC`

Переменная DISTRO_FEATURES_LIBC больше не применяется. Возможность настройки glibc с помощью kconfig была удалена некоторое время назад и свойства libc-* утратили силу. Следует удалить DISTRO_FEATURES_LIBC из своих заданий.

4.15.6. Корректировки значений лицензий

Socat – значение LICENSE изменено на GPLv2 вместо GPLv2+.
libgfortran – задана лицензия GPL-3.0-with-GCC-exception.
elfutils – удалено значение Elfutils-Exception и установлено GPLv2 для общих библиотек.

4.15.7. Изменение подготовки пакетов

bind – двоичный файл nsupdate перенесен в пакет bind-utils.
Разделение отладки, принятое по умолчанию, было изменено для создания отдельных пакетов с исходным кодом (package_name-dbg и package_name-src). При использовании dbg-pkgs в IMAGE_FEATURES для получения отладочных символов можно добавить в переменную src-pkgs,если нужны исходные коды. Пакеты с исходным кодом по умолчанию сохранены вSDK, если в SDKIMAGE_FEATURES не задано их исключение.
Монтирование с помощью util-linux. Файл /etc/default/mountall перенесен в субпакет mount.
Разделение двоичных файлов util-linux – сейчас каждый двоичный исполняемый файл выделен в свой пакет для более тонкого управления. Основной пакет util-linux втягивает отдельные двоичные пакеты с помощью переменных RRECOMMENDS и RDEPENDS. В результате образы не будут иметь видимых изменений, пока не установлена переменная NO_RECOMMENDATIONS.
netbase/base-files – файл /etc/hosts перенесен из netbase в base-files.
tzdata – основной пакет преобразован в пустой мета-пакет, который по умолчанию втягивает все пакеты tzdata.
lrzsz удален из packagegroup-self-hosted и packagegroup-core-tools-testapps. Потребность в X/Y/ZModem маловероятна в современных системах. Если вы включали пакет lrzsz на основе упомянутых групп, потребуется добавить его явно.

4.15.8. Удаленные задания

gcc – задания версии 7.3 исключены, версия 8.3 сохраняется.
linux-yocto – исключены задания версий 4.14 и 4.18, версии 4.19 и 5.0 сохранены.
go – исключены задания версии 1.9, версии 1.11 и 1.12 сохранены.
xvideo-tests устарело.
libart-lgpl устарело.
gtk-icon-utils-native сейчас предоставляется заданием gtk+3-native
gcc-cross-initial больше не нужно, взамен используется gcc-cross/gcc-crosssdk.
gcc-crosssdk-initial больше не нужно, взамен используется gcc-cross/gcc-crosssdk.
glibc-initial удалено, поскольку преимущества наличия для site_config перевешиваются сложностью сборки.

4.15.9. Удаленные классы

distutils-tools никогда не использовался.
bugzilla.bbclass устарел.
distrodata – функциональность заменена более современной реализацией на основе tinfoil.

4.15.10. Прочие изменения

Каталог distro репозитория Poky удален из каталога сценариев верхнего уровня.
Perl сейчас выполняет сборку для целевых систем с использованием perl-cross для улучшения сопровождаемости и повышения производительности сборки. Это изменение не должно вызывать проблем, если вы не меняли сильно свое задание Perl.
arm-tunes – удалена опция -march, если уже добавлено mcpu.
update-alternatives – файл преобразования переименован в PACKAGE_PREPROCESS_FUNCS.
base/pixbufcache - удален устаревший код sstatecompletions.
native class – включена обработка RDEPENDS.
inetutils - в задании отключена оболочка rsh.

Продолжение

1Windows Subsystem for Linux.

2Network File System – сетевая файловая система.

3Software Development Kit – комплект для разработки программ.

4Quality Assurance – гарантия (контроль) качества.

5Board Support Package.

6В установленном по умолчанию файле local.conf эти строки присутствуют, поэтому при сборке образов для систем без монитора следует их закомментировать.

7Filesystem Hierarchy Standard – стандарт иерархии файловых систем.

8Application Development Toolkit.

9GLib Introspective Repository – репозиторий самоанализа Glib.

10В двоичном файле отсутствует GNU_HASH.

11Position Independent Executables – независимые от положения исполняемые файлы.

12Return Oriented Programming – ориентированное на возврат программирование.

13Device Tree Binary.

14Flattened image tree.

Глава 1. Системные требования

1.1. Поддерживаемые дистрибутивы Linux

1.2. Пакеты, требуемые на сборочном хосте

1.2.1. Ubuntu и Debian

1.2.2. Fedora

1.2.3. OpenSUSE

1.2.4. CentOS

1.3. Требуемые версии Git, tar и Python

1.3.1. Загрузка собранного архива buildtools

1.3.2. Сборка buildtools

Глава 2. Терминология YP

Глава 3. Выпуски YP и создание стабильного выпуска

3.1. Основные и второстепенные выпуски

3.2. Кодовые имена основных выпусков

3.3. Процесс подготовки стабильного выпуска

3.4. Тестирование и контроль качества

Глава 4. Переход на новые выпуски YP

4.1. Общие вопросы

4.2. Переход на YP 1.3

4.2.1. Локальная конфигурация

4.2.1.1. SSTATE_MIRRORS

4.2.1.2. bblayers.conf

4.2.2. Задания

4.2.2.1. Пробелы в функциях Python

4.2.2.2. proto= в SRC_URI

4.2.2.3. nativesdk

4.2.2.4. Задания для задач

4.2.2.5. IMAGE_FEATURES

4.2.2.6. Удаленные задания

4.2.3. Именование ядер Linux

4.3. Переход на YP 1.4

4.3.1. BitBake

4.3.2. Поведение при сборке

4.3.3. Прокси и извлечение исходного кода

4.3.4. Пользовательские интерфейсные файлы (изменение netbase)

4.3.5. Удаленная отладка

4.3.6. Переменные

4.3.7. Управление пакетами целевой платформы с помощью RPM

4.3.8. Перенос заданий

4.3.9. Удаления и переименования

4.4. Переход на YP 1.5

4.4.1. Изменения зависимостей для сборочного хоста

4.4.2. atom-pc BSP

4.4.3. BitBake

4.4.4. Предупреждения QA

4.4.5. Изменение схемы каталогов

4.4.6. Сокращенные значения Git SRCREV

4.4.7. IMAGE_FEATURES

4.4.8. /run

4.4.9. Удаление базы данных менеджера пакетов из заданий для образов

4.4.10. Повторная сборка образов только при наличии изменений

4.4.11. Задания для задач

4.4.12. BusyBox

4.4.13. Автоматизированное тестирование образов

4.4.14. История сборки

4.4.15. udev

4.4.16. Удаленные и переименованные задания

4.4.17. Прочие изменения

4.5. Переход на YP 1.6

4.5.1. Класс archiver

4.5.2. Изменения в пакетах

4.5.3. BitBake

4.5.3.1. Требование к соответствию ветвей для сборщика Git

4.5.3.2. Подстановки определений Python

4.5.3.3. Сборщик SVK

4.5.3.4. Перенаправление консольного вывода ошибок

4.5.3.5. Переопределения task-taskname

4.5.4. Изменения переменных

4.5.4.1. TMPDIR

4.5.4.2. PRINC

4.5.4.3. IMAGE_TYPES

4.5.4.4. COPY_LIC_MANIFEST

4.5.4.5. COPY_LIC_DIRS

4.5.4.6. PACKAGE_GROUP

4.5.4.7. Поведение команд предварительной и пост-обработки

4.5.5. Тестирование пакетов (ptest)

4.5.6. Изменение сборки

4.5.7. qemu-native

4.5.8. core-image-basic

1.3.1. Загрузка собранного архива `buildtools`

1.3.2. Сборка `buildtools`

4.4.2. `atom-pc` BSP

4.4.6. Сокращенные значения Git `SRCREV`

4.4.7. `IMAGE_FEATURES`

4.4.8. `/run`

4.4.15. `udev`

4.5.1. Класс `archiver`

4.5.3.5. Переопределения `task-taskname`

4.5.4.1. `TMPDIR`

4.5.4.2. `PRINC`

4.5.4.3. `IMAGE_TYPES`

4.5.4.4. `COPY_LIC_MANIFEST`

4.5.4.5. `COPY_LIC_DIRS`

4.5.4.6. `PACKAGE_GROUP`

4.5.7. `qemu-native`

4.5.8. `core-image-basic`

4.5.10. Опции `CFLAGS`

4.5.13. Поставщик `update-alternative`

4.5.14. Переопределение `virtclass`

4.6.1. Изменение опций QEMU `PACKAGECONFIG` в файле `local.conf`

4.6.5. Замена `eglibc 2.19` на `glibc 2.20`

4.9.2. Нижний регистр для переменной `OVERRIDES`

4.9.3. Параметр раскрытия функций `getVar()` и `getVarFlag()` стал обязательным

4.9.5. Возвращение `libexecdir` к `${prefix}/libexec`

4.10.3. Включено удаление старых образов и других файлов из `tmp/deploy`

4.10.4.5. Архив `buildtools` включает Python 3

4.10.6. `${B}` больше не служит для задач рабочим каталогом по умолчанию

4.10.7. Сценарий `runqemu` переписан на Python