Home > Articles

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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020