- 7.1 Core Images-Linux Distribution Blueprints
- 7.2 Building Images from Scratch
- 7.3 Image Options
- 7.4 Distribution Configuration
- 7.5 External Layers
- 7.6 Hob
- 7.7 Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
7.4 Distribution Configuration
The build system provides a mechanism for global configuration that applies to all images built. This mechanism is called distribution configuration or distribution policy. It is simply a configuration file that contains variable settings. The distribution configuration is included through the DISTRO variable setting in the build environment configuration file conf/local.conf:
DISTRO = "poky"
The variable setting corresponds to a distribution configuration file whose base name is the same as the variable’s argument with the file extension .conf. For the preceding example, the build system searches for a distribution configuration file with the name poky.conf in the subdirectory conf/distro in all metadata layers included by the build environment.
7.4.1 Standard Distribution Policies
The Yocto Project provides several distribution configuration files for standard configuration policies:
poky: Poky is the default policy for the Yocto Project’s reference distribution Poky. It is a good choice for getting started with the Yocto Project and as a template for your own distribution configuration files.
poky-bleeding: This distribution configuration is based on poky but sets the versions for all packages to the latest revision. It is commonly used by the Yocto Project developers for integration test purposes. You may, of course, use it, but be aware that there could be issues with packages with incompatible versions.
poky-lsb: This distribution configuration is for a stack that complies with LSB. It is preferably used with the core-image-lsb image target and image targets derived from it. It inherits the base settings from poky and adds global configuration settings to enable security and includes default libraries required for LSB compliance.
poky-tiny: This distribution configuration tailors the settings to yield a very compact Linux OS stack for embedded devices. It is based on poky but provides only the bare minimum functionality necessary to support the hardware and a BusyBox environment. It does not support any video but only a serial console. Because of its slim configuration, only the core-image-minimal image target and image targets based on it can be built with the poky-tiny distribution configuration.
The standard distribution policies, particularly poky, are good starting points for your own distribution configuration. Let’s have a closer look at the poky distribution configuration to understand how distribution policies are set and how we can use them for our own projects.
7.4.2 Poky Distribution Policy
You can find the file poky.conf containing the Poky distribution policy in the meta-yocto/conf/distro directory of the build system. We replicated its contents here for convenience, reformatted the file to fit on the page, grouped the variable settings into logical blocks, and added some comments (see Listing 7-12).
Listing 7-12 Poky Distribution Policy meta-yocto/conf/distro/poky.conf
# Distribution Information
DISTRO = "poky"
DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
DISTRO_VERSION = "1.6+snapshot-${DATE}"
DISTRO_CODENAME = "next"
MAINTAINER = "Poky <poky@yoctoproject.org>"
TARGET_VENDOR = "-poky"
# SDK Information
SDK_NAME = \
"${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
SDK_VERSION := \
"${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
SDK_VENDOR = "-pokysdk"
SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
# Distribution Features
# Override these in poky based distros
POKY_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland"
POKY_DEFAULT_EXTRA_RDEPENDS = "packagegroup-core-boot"
POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} \
${POKY_DEFAULT_DISTRO_FEATURES}"
# Preferred Versions for Packages
PREFERRED_VERSION_linux-yocto ?= "3.14%"
PREFERRED_VERSION_linux-yocto_qemux86 ?= "3.14%"
PREFERRED_VERSION_linux-yocto_qemux86-64 ?= "3.14%"
PREFERRED_VERSION_linux-yocto_qemuarm ?= "3.14%"
PREFERRED_VERSION_linux-yocto_qemumips ?= "3.14%"
PREFERRED_VERSION_linux-yocto_qemumips64 ?= "3.14%"
PREFERRED_VERSION_linux-yocto_qemuppc ?= "3.14%"
# Dependencies
DISTRO_EXTRA_RDEPENDS += " ${POKY_DEFAULT_EXTRA_RDEPENDS}"
DISTRO_EXTRA_RRECOMMENDS += " ${POKY_DEFAULT_EXTRA_RRECOMMENDS}"
POKYQEMUDEPS = "${@bb.utils.contains( \
"INCOMPATIBLE_LICENSE", "GPLv3", "", "qemu-config",d)}"
DISTRO_EXTRA_RDEPENDS_append_qemuarm = " ${POKYQEMUDEPS}"
DISTRO_EXTRA_RDEPENDS_append_qemumips = " ${POKYQEMUDEPS}"
DISTRO_EXTRA_RDEPENDS_append_qemuppc = " ${POKYQEMUDEPS}"
DISTRO_EXTRA_RDEPENDS_append_qemux86 = " ${POKYQEMUDEPS}"
DISTRO_EXTRA_RDEPENDS_append_qemux86-64 = " ${POKYQEMUDEPS}"
# Target C Library Configuration
TCLIBCAPPEND = ""
# Target Architectures for QEMU
# (see meta/recipes-devtools/qemu/qemu-targets.inc)
QEMU_TARGETS ?= "arm i386 mips mipsel ppc x86_64"
# Other QEMU_TARGETS "mips64 mips64el sh4"
# Package Manager Configuration
EXTRAOPKGCONFIG = "poky-feed-config-opkg"
# Source Mirrors
PREMIRRORS ??= "\
bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
cvs://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
gitsm://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
hg://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
osc://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
p4://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
svk://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
svn://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n"
MIRRORS =+ "\
ftp://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
http://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
https://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n"
# Build System Configuration
# Configuration File and Directory Layout Versions
LOCALCONF_VERSION = "1"
LAYER_CONF_VERSION ?= "6"
#
# OELAYOUT_ABI allows us to notify users when the format of TMPDIR changes
# in an incompatible way. Such changes should usually be detailed in the
# commit that breaks the format and have been previously discussed on the
# mailing list with general agreement from the core team.
#
OELAYOUT_ABI = "8"
# Default hash policy for distro
BB_SIGNATURE_HANDLER ?= 'OEBasicHash'
# Build System Checks
# add poky sanity bbclass
INHERIT += "poky-sanity"
# The CONNECTIVITY_CHECK_URIs are used to test whether we can successfully
# fetch from the network (and warn you if not). To disable the test, set
# the variable to be empty.
# Git example url: \
git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD
CONNECTIVITY_CHECK_URIS ?= " \
https://eula-downloads.yoctoproject.org/index.php \
http://bugzilla.yoctoproject.org/report.cgi"
SANITY_TESTED_DISTROS ?= " \
Poky-1.4 \n \
Poky-1.5 \n \
Poky-1.6 \n \
Ubuntu-12.04 \n \
Ubuntu-13.10 \n \
Ubuntu-14.04 \n \
Fedora-19 \n \
Fedora-20 \n \
CentOS-6.4 \n \
CentOS-6.5 \n \
Debian-7.0 \n \
Debian-7.1 \n \
Debian-7.2 \n \
Debian-7.3 \n \
Debian-7.4 \n \
SUSE-LINUX-12.2 \n \
openSUSE-project-12.3 \n \
openSUSE-project-13.1 \n \
"
# QA check settings - a little stricter than the OE-Core defaults
WARN_QA = "textrel files-invalid incompatible-license xorg-driver-abi \
libdir unknown-configure-option"
ERROR_QA = "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
perms useless-rpaths rpaths staticdev ldflags pkgvarcheck \
already-stripped compile-host-path dep-cmp \
installed-vs-shipped install-host-path packages-list \
perm-config perm-line perm-link pkgv-undefined \
pn-overrides split-strip var-undefined version-going-backwards"
The file shown in the listing is from the head of the Yocto Project Git repository at the writing of this book. Depending on what version of the Yocto Project tools you are using, this file may look slightly different. The file is an example of a distribution policy only. It provides the variable settings most commonly associated with the configuration of a distribution. You are not limited to using just the settings shown in the listing, and you can remove settings if you do not need them for your project.
Distribution Information
This section of the distribution policy file contains settings for general information about the distribution.
DISTRO: Short name of the distribution. The value must match the base name of the distribution configuration file.
DISTRO_NAME: The long name of the distribution. Various recipes reference this variable. Its contents are shown on the console boot prompt.
DISTRO_VERSION: Distribution version string. It is referenced by various recipes and used in filenames’ distribution artifacts. It is shown on the console boot prompt.
DISTRO_CODENAME: A code name for the distribution. It is currently used only by the LSB recipes and copied into the lsb-release system configuration file.
MAINTAINER: Name and e-mail address of the distribution maintainer.
TARGET_VENDOR: Target vendor string that is concatenated with various variables, most notably target system (TARGET_SYS). TARGET_SYS is a concatenation of target architecture (TARGET_ARCH), target vendor (TARGET_VENDOR), and target operating system (TARGET_OS), such as i586-poky-linux. The three parts are delimited by hyphens. The TARGET_VENDOR string must be prefixed with the hyphen, and TARGET_OS must not. This is one of the many unfortunate inconsistencies of the OpenEmbedded build system. You may want to set this variable to your or your company’s name.
SDK Information
The settings in this section provide the base configuration for the SDK.
SDK_NAME: The base name that the build system uses for SDK output files. It is derived by concatenating the DISTRO, TCLIBC, SDK_ARCH, IMAGE_BASENAME, and TUNE_PKGARCH variables with hyphens. There is not much reason for you to change that string from its default setting, as it provides all the information needed to distinguish different SDKs.
SDK_VERSION: SDK version string, which is commonly set to DISTRO_VERSION.
SDK_VENDOR: SDK vendor string, which serves a similar purpose as TARGET_VENDOR. Like TARGET_VENDOR, the string must be prefixed with a hyphen.
SDKPATH: Default installation path for the SDK. The SDK installer offers this path to the user during installation of an SDK. The user can accept it or enter an alternative path. The default value /opt/${DISTRO}/${SDK_VERSION} installs the SDK into the /opt system directory, which requires root privileges. A viable alternative would be to install the SDK into the user’s home directory by setting SDKPATH = "${HOME}/${DISTRO}/${SDK_VERSION}".
Distribution Features
These feature settings provide specific functionality for the distribution.
DISTRO_FEATURES: A list of distribution features that enable support for certain functionality within software packages. The assignment in the poky.conf distribution policy file includes DISTRO_FEATURES_DEFAULT and DISTRO_FEATURES_LIBC. Both contain default distribution feature settings. We discuss distribution features and how they work and the default configuration in the next two sections.
Preferred Versions
Version settings prescribe particular versions for packages rather than the default versions.
PREFERRED_VERSION: Using PREFERRED_VERSION allows setting particular versions for software packages if you do not want to use the latest version, as it is the default. Commonly, that is done for the Linux kernel but also for software packages on which your application software has strong version dependencies.
Dependencies
These settings are declarations for dependencies required for distribution runtime.
DISTRO_EXTRA_RDEPENDS: Sets runtime dependencies for the distribution. Dependencies declared with this variable are required for the distribution. If these dependencies are not met, building the distributions fails.
DISTRO_EXTRA_RRECOMMENDS: Packages that are recommended for the distribution to provide additional useful functionality. These dependencies are added if available but building the distribution does not fail if they are not met.
Toolchain Configuration
These settings configure the toolchain used for building the distribution.
TCMODE: This variable selects the toolchain that the build system uses. The default value is default, which selects the internal toolchain built by the build system (gcc, binutils, etc.). The setting of the variable corresponds to a configuration file tcmode-${TCMODE}.inc, which the build system locates in the path conf/distro/include. This allows including an external toolchain with the build system by including a toolchain layer that provides the necessary tools as well as the configuration file. If you are using an external toolchain, you must ensure that it is compatible with the Poky build system.
TCLIBC: Specifies the C library to be used. The build system currently supports EGLIBC, uClibc, and musl. The setting of the variable corresponds to a configuration file tclibc-${TCLIBC).inc that the build system locates in the path conf/distro/include. These configuration files set preferred providers for libraries and more.
TCLIBCAPPEND: The build system appends this string to other variables to distinguish build artifacts by C library. If you are experimenting with different C libraries, you may want to use the settings
TCLIBCAPPEND = "-${TCLIBC}"
TMPDIR .= "${TCLIBCAPPEND}"in your distribution configuration, which creates a separate build output directory structure for each C library.
Mirror Configuration
The settings in this section configure the mirrors for downloading source packages.
PREMIRRORS and MIRRORS: The Poky distribution adds these variables to set its mirror configuration to use the Yocto Project repositories as a source for downloads. If you want to use your own mirrors, you can add them to your distribution configuration file. However, since mirrors are not strictly distribution settings, you may want to add these variables to the local.conf file of your build environment. Another alternative would be to add them to the layer.conf file of a custom layer.
Build System Configuration
These settings define the requirements for the build system.
LOCALCONF_VERSION: Sets the expected or required version for the build environment configuration file local.conf. The build system compares this value to the value of the variable CONF_VERSION in local.conf. If LOCALCONF_VERSION is a later version than CONF_VERSION, the build system may be able to automatically upgrade local.conf to the newer version. Otherwise, the build system exits with an error message.
LAYER_CONF_VERSION: Sets the expected or required version for the bblayers.conf configuration file of a build environment. The build system compares this version to the value of LCONF_VERSION set by bblayers.conf. If LAYER_CONF_VERSION is a later version than LCONF_VERSION, the build system may be able to automatically upgrade bblayers.conf to the newer version. Otherwise, the build system exits with an error message.
OELAYOUT_ABI: Sets the expected or required version for the layout of the output directory TMPDIR. The build system stores the actual layout version in the file abi_version inside of TMPDIR. If the two are incompatible, the build system exits with an error message. This typically happens only if you are using a newer version of the build system with a build environment that was created by a previous version and the layout changed incompatibly. Deleting TMPDIR resolves the issue by re-creating the directory.
BB_SIGNATURE_HANDLER: The signature handler used for signing shared state cache entries and creating stamp files. The value references a signature handler function that, because of its complexity, is typically implemented in Python. The code in meta/lib/oe/sstatesig.py implements OEBasic and OEBasicHash based on the BitBake signature generators SignatureGeneratorBasic and SignatureGeneratorBasicHash defined by bitbake/lib/bb/siggen.py and illustrates how to insert your own signature handler function. The two signature handlers are principally the same, but OEBasicHash includes the task code in the signature, which causes any change to metadata to invalidate stamp files and shared state cache entries without explicitly changing package revision numbers. Using the default value of OEBasicHash is typically sufficient for most applications.
Build System Checks
These configuration variables control various validators to catch build system misconfigurations.
INHERIT += "poky-sanity": Inherits the class poky-sanity, which is required to perform the build system checks. It is recommended that you include this directive in your own distribution configuration files.
CONNECTIVITY_CHECK_URIS: A list of URIs that the build system tries to verify network connectivity. In the case of Poky, these point to files on the Yocto Project’s high-availability infrastructure. If you intend to use your own mirrors for downloading source packages, you could use URIs pointing to files on your mirror servers to verify proper connectivity.
SANITY_TESTED_DISTROS: A list of Linux distributions the Poky build system has been tested on. The build system verifies the Linux distribution it is running on against this list. If that distribution is not in the list, Poky displays a warning message and starts the build process regardless. Poky runs on most current Linux distributions, and in most cases, building works just fine even if the distribution is not officially supported.
QA Checks
The QA checks are defined and implemented by meta/classes/insane.bbclass. This class also defines the QA tasks that are included with the build process. QA checks are performed after configuration, packaging, and other build tasks. The following two variables define which QA checks cause warning messages and which checks cause the build system to terminate the build with an error message:
WARN_QA: A list of QA checks that create warning messages, but the build continues
ERROR_QA: A list of QA checks that create error messages, and the build terminates
The preceding list represents the most common variable settings used by a distribution configuration. For your own distribution configuration, you may add and/or omit variables as needed.
7.4.3 Distribution Features
Distribution features enable support for certain functionality within software packages. Adding a distribution feature to the variable DISTRO_FEATURES adds the functionality of this feature to software packages that support it during build time. For instance, if a software package can be built for console as well as graphical user interfaces, then adding x11 to DISTRO_FEATURES configures that software package so that it is built with X11 support. Unlike the x11 image feature, this does not mean that the X11 packages are installed in your target root filesystem. The distribution feature only prepares a software package for X11 support so that it uses X11 on a system where the X11 base packages are installed.
Using DISTRO_FEATURES gives you granular control over how software packages are built. If you do not need a particular functionality, omitting the distribution feature enabling it typically results in a smaller footprint for a particular software package.
Using
$ grep -R DISTRO_FEATURES *
from the installation directory of your build system gives you a list of all the recipes and include files that use DISTRO_FEATURES to conditionally modify configuration settings or build processes dependent on what distribution features are enabled.
Recipes typically scan DISTRO_FEATURES using
bb.utils.contains('DISTRO_FEATURES', <feature>, <true_val>, <false_val>)
to determine if a particular distribution feature is enabled by DISTRO_FEATURES. The function returns true_val if DISTRO_FEATURES contains feature and false_val otherwise. That makes it convenient for the developer to assign values to BitBake variables or use the function in if-then-else statements. Typically, this is used by the do_configure task to modify the configuration based on DISTRO_FEATURES. For some packages, it may provide flags to makefiles.
A prime example is the recipe to build the EGLIBC library. EGLIBC allows enabling functionality by setting configuration options. The file meta/recipes-core/egligc/egilbc-options.inc, which is included by the recipe, sets the configuration options based on the distribution features provided by DISTRO_FEATURES.
The following list shows the most common distribution features that you can add to DISTRO_FEATURES to enable functionality in software packages globally across your distribution:
alsa: Enable support for the Advanced Linux Sound Architecture (ALSA), including the installation of open source compatibility modules if available.
bluetooth: Enable support for Bluetooth.
cramfs: Enable support for the compressed filesystem CramFS.
directfb: Enable support for DirectFB.
ext2: Enable support and include tools for devices with internal mass storage devices such as hard disks instead of flash devices only.
ipsec: Enable support for authentication and encryption using Internet Protocol Security (IPSec).
ipv6: Enable support for Internet Protocol version 6 (IPv6).
irda: Enable support for wireless infrared data communication as specified by the Infrared Data Association (IrDA).
keyboard: Enable keyboard support, which includes loading of keymaps during boot of the system.
nfs: Enable client NFS support for mounting NFS exports on the system.
opengl: Include the Open Graphics Library (OpenGL), which is an application programming interface for rendering 2D and 3D graphics. OpenGL runs on different platforms and provides bindings for most common programming languages.
pci: Enable support for the PCI bus.
pcmcia: Enable PCMCIA and CompactFlash support.
ppp: Enable Point-to-Point Protocol (PPP) support for dial-up networking.
smbfs: Enable support and include clients for Microsoft’s Server Message Block (SMB) for sharing remote filesystems, printers, and other devices over networks.
systemd: Include support for the system management daemon (systemd) that replaces the SysVinit script-based system for starting up and shutting down a system.
sysvinit: Include support for the SysVinit system manager.
usbgadget: Enable support for the Linux-USB Gadget API Framework that allows a Linux device to act like a USB device (slave role) when connected to another system.
usbhost: Enable USB host support allowing client devices such as keyboards, mice, cameras, and more to be connected to the system’s USB ports and detected by it.
wayland: Enable support for the Wayland compositor protocol and include the Weston compositor.
wifi: Enable WiFi support.
x11: Include the X11 server and libraries.
The list does not include the distribution features for the configuration of the C library. These distribution features all begin with libc-. They enable support for functionality provided by the C library if the C library is configurable like the Yocto Project’s default C library glibc. If you are using glibc, then you do not have to worry about setting these distribution features, as they are inherited from the default distribution setup, which is covered in the next section.
If you have already been working with the Yocto Project, you may have noticed that there is also a variable called MACHINE_FEATURES and that the permissible list of machine features has a large intersection with the distribution feature list. For example, both MACHINE_FEATURES and DISTRO_FEATURES provide the feature bluetooth. Enabling Bluetooth in DISTRO_FEATURES causes the Bluetooth packages for hardware support to be installed and also enables Bluetooth support for various software packages. However, enabling Bluetooth in MACHINE_FEATURES only causes the Bluetooth packages for hardware support to be installed. This gives you control over functionality on the machine and the distribution level. We discuss machine features in detail when we are looking into Yocto Project board support packages.
7.4.4 System Manager
The build system supports SysVinit, the traditional script-based system manager, as well as the system management daemon (systemd), a replacement for SysVinit that offers better prioritization and dependency handling between services and the ability to start services in parallel to speed up the boot sequence.
SysVinit is the default system manager for Linux distributions built by Poky. You do not have to change the configuration if you want to use SysVinit.
To enable systemd, you need to add it to the distribution features and set it as the system manager. Add the following to your distribution configuration file:
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
The first line installs systemd in the root filesystem. The second line enables it as the system manager. Installing and enabling systemd does not remove SysVinit from your root filesystem if it is also included in DISTRO_FEATURES. If you are using one of the standard distribution configurations, such as poky, then you can remove it from DISTRO_FEATURES with
DISTRO_FEATURES_BACKFULL_CONSIDERED = "sysvinit"
which is easier than redefining DISTRO_FEATURES altogether. For your own distribution configuration, you can of course simply omit SysVinit from the DISTRO_FEATURES list.
The SysVinit initscripts to start the individual system services are typically part of the package that provides the service. To conserve space in the root filesystem, you may not want to install the initscripts if you want to use systemd exclusively. Use
VIRTUAL-RUNTIME_initscripts = ""
to prevent the build system from installing the SysVinit initscripts.
A word of caution: some daemons may not yet have been adapted for use with systemd and therefore systemd service files are not available. If you come across such software, you may have to do the adaptation yourself. If you do so, please consider submitting your work to upstream.
7.4.5 Default Distribution Setup
The OE Core metadata layer provides default distribution setup through the file meta/conf/distro/defaultsetup.conf and a series of other files included by it (see Listing 7-13). It is not quite obvious how this default distribution setup is included into the build configuration, as this file is not included by distribution policy configuration files such as poky.conf, which we discussed earlier. Instead, the file is included by BitBake’s main configuration file, bitbake.conf.
Knowing about defaultsetup.conf and understanding its settings is important because your own distribution policy configuration may extend or overwrite some of the default variable settings provided by it. If you do not set up the default distribution correctly, you may inadvertently lose important default settings, and your distribution build may fail or not yield the desired results.
Listing 7-13 Default Distribution Setup meta/conf/distro/defaultsetup.conf
include conf/distro/include/default-providers.inc
include conf/distro/include/default-versions.inc
include conf/distro/include/default-distrovars.inc
include conf/distro/include/world-broken.inc
TCMODE ?= "default"
require conf/distro/include/tcmode-${TCMODE}.inc
TCLIBC ?= "eglibc"
require conf/distro/include/tclibc-${TCLIBC}.inc
# Allow single libc distros to disable this code
TCLIBCAPPEND ?= "-${TCLIBC}"
TMPDIR .= "${TCLIBCAPPEND}"
CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + \
str(d.getVar('MACHINE', True))][bool(d.getVar('MACHINE', \
True))]}${@['', '/' + str(d.getVar('SDKMACHINE', True))] \
[bool(d.getVar('SDKMACHINE', True))]}"
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
INHERIT_DISTRO ?= "debian devshell sstate license"
INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} \
${INHERIT_BLACKLIST}"
The file first includes three other files with default settings: default-providers.inc, default-versions.inc, and default-distrovars.inc. The names for these files are indicative of what the file content is providing.
The file default-distrovars.inc in particular provides default settings for DISTRO_FEATURES, DISTRO_FEATURES_DEFAULT, DISTRO_FEATURES_LIBC, and DISTRO_FEATURES_LIBC_DEFAULT. If you are going to set DISTRO_FEATURES in your own distribution policy configuration file, you need to pay attention that you do not inadvertently remove the default settings by overwriting the variable. A safe way of doing so is to use an assignment like
DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} \
${MY_DISTRO_FEATURES}"
MY_DISTRO_FEATURES = "<distro features>"
which includes all default settings and adds another variable to include additional distribution features as needed.
The configuration file defaultsetup.conf also sets the defaults for TCMODE and TCLIBC and includes their respective configuration files, as described earlier.