poky/documentation/ref-manual/migration-2.1.rst - mdmillerii/openbmc - Gitiles

 Moving to the Yocto Project 2.1 Release (krogoth)
 =================================================

 This section provides migration information for moving to the Yocto
 Project 2.1 Release (codename "krogoth") from the prior release.

 .. _migration-2.1-variable-expansion-in-python-functions:

 Variable Expansion in Python Functions
 --------------------------------------

 Variable expressions, such as ``${VARNAME}`` no longer expand
 automatically within Python functions. Suppressing expansion was done to
 allow Python functions to construct shell scripts or other code for
 situations in which you do not want such expressions expanded. For any
 existing code that relies on these expansions, you need to change the
 expansions to expand the value of individual variables through
 ``d.getVar()``. To alternatively expand more complex expressions, use
 ``d.expand()``.

 .. _migration-2.1-overrides-must-now-be-lower-case:

 Overrides Must Now be Lower-Case
 --------------------------------

 The convention for overrides has always been for them to be lower-case
 characters. This practice is now a requirement as BitBake's datastore
 now assumes lower-case characters in order to give a slight performance
 boost during parsing. In practical terms, this requirement means that
 anything that ends up in :term:`OVERRIDES` must now
 appear in lower-case characters (e.g. values for ``MACHINE``,
 ``TARGET_ARCH``, ``DISTRO``, and also recipe names if
 ``_pn-``\ recipename overrides are to be effective).

 .. _migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory:

 Expand Parameter to ``getVar()`` and ``getVarFlag()`` is Now Mandatory
 ----------------------------------------------------------------------

 The expand parameter to ``getVar()`` and ``getVarFlag()`` previously
 defaulted to False if not specified. Now, however, no default exists so
 one must be specified. You must change any ``getVar()`` calls that do
 not specify the final expand parameter to calls that do specify the
 parameter. You can run the following ``sed`` command at the base of a
 layer to make this change:
 ::

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

 .. note::

    The reason for this change is that it prepares the way for changing
    the default to True in a future Yocto Project release. This future
    change is a much more sensible default than False. However, the
    change needs to be made gradually as a sudden change of the default
    would potentially cause side-effects that would be difficult to
    detect.

 .. _migration-2.1-makefile-environment-changes:

 Makefile Environment Changes
 ----------------------------

 :term:`EXTRA_OEMAKE` now defaults to "" instead of
 "-e MAKEFLAGS=". Setting ``EXTRA_OEMAKE`` to "-e MAKEFLAGS=" by default
 was a historical accident that has required many classes (e.g.
 ``autotools``, ``module``) and recipes to override this default in order
 to work with sensible build systems. When upgrading to the release, you
 must edit any recipe that relies upon this old default by either setting
 ``EXTRA_OEMAKE`` back to "-e MAKEFLAGS=" or by explicitly setting any
 required variable value overrides using ``EXTRA_OEMAKE``, which is
 typically only needed when a Makefile sets a default value for a
 variable that is inappropriate for cross-compilation using the "="
 operator rather than the "?=" operator.

 .. _migration-2.1-libexecdir-reverted-to-prefix-libexec:

 ``libexecdir`` Reverted to ``${prefix}/libexec``
 ------------------------------------------------

 The use of ``${libdir}/${BPN}`` as ``libexecdir`` is different as
 compared to all other mainstream distributions, which either uses
 ``${prefix}/libexec`` or ``${libdir}``. The use is also contrary to the
 GNU Coding Standards (i.e.
 https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
 that suggest ``${prefix}/libexec`` and also notes that any
 package-specific nesting should be done by the package itself. Finally,
 having ``libexecdir`` change between recipes makes it very difficult for
 different recipes to invoke binaries that have been installed into
 ``libexecdir``. The Filesystem Hierarchy Standard (i.e.
 https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) now
 recognizes the use of ``${prefix}/libexec/``, giving distributions the
 choice between ``${prefix}/lib`` or ``${prefix}/libexec`` without
 breaking FHS.

 .. _migration-2.1-ac-cv-sizeof-off-t-no-longer-cached-in-site-files:

 ``ac_cv_sizeof_off_t`` is No Longer Cached in Site Files
 --------------------------------------------------------

 For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
 class, ``ac_cv_sizeof_off_t`` is no longer cached in the site files for
 ``autoconf``. The reason for this change is because the
 ``ac_cv_sizeof_off_t`` value is not necessarily static per architecture
 as was previously assumed. Rather, the value changes based on whether
 large file support is enabled. For most software that uses ``autoconf``,
 this change should not be a problem. However, if you have a recipe that
 bypasses the standard :ref:`ref-tasks-configure` task
 from the ``autotools`` class and the software the recipe is building
 uses a very old version of ``autoconf``, the recipe might be incapable
 of determining the correct size of ``off_t`` during ``do_configure``.

 The best course of action is to patch the software as necessary to allow
 the default implementation from the ``autotools`` class to work such
 that ``autoreconf`` succeeds and produces a working configure script,
 and to remove the overridden ``do_configure`` task such that the default
 implementation does get used.

 .. _migration-2.1-image-generation-split-out-from-filesystem-generation:

 Image Generation is Now Split Out from Filesystem Generation
 ------------------------------------------------------------

 Previously, for image recipes the :ref:`ref-tasks-rootfs`
 task assembled the filesystem and then from that filesystem generated
 images. With this Yocto Project release, image generation is split into
 separate :ref:`ref-tasks-image` tasks for clarity both in
 operation and in the code.

 For most cases, this change does not present any problems. However, if
 you have made customizations that directly modify the ``do_rootfs`` task
 or that mention ``do_rootfs``, you might need to update those changes.
 In particular, if you had added any tasks after ``do_rootfs``, you
 should make edits so that those tasks are after the
 :ref:`ref-tasks-image-complete` task rather than
 after ``do_rootfs`` so that your added tasks run at the correct
 time.

 A minor part of this restructuring is that the post-processing
 definitions and functions have been moved from the
 :ref:`image <ref-classes-image>` class to the
 :ref:`rootfs-postcommands <ref-classes-rootfs*>` class. Functionally,
 however, they remain unchanged.

 .. _migration-2.1-removed-recipes:

 Removed Recipes
 ---------------

 The following recipes have been removed in the 2.1 release:

 -  ``gcc`` version 4.8: Versions 4.9 and 5.3 remain.

 -  ``qt4``: All support for Qt 4.x has been moved out to a separate
    ``meta-qt4`` layer because Qt 4 is no longer supported upstream.

 -  ``x11vnc``: Moved to the ``meta-oe`` layer.

 -  ``linux-yocto-3.14``: No longer supported.

 -  ``linux-yocto-3.19``: No longer supported.

 -  ``libjpeg``: Replaced by the ``libjpeg-turbo`` recipe.

 -  ``pth``: Became obsolete.

 -  ``liboil``: Recipe is no longer needed and has been moved to the
    ``meta-multimedia`` layer.

 -  ``gtk-theme-torturer``: Recipe is no longer needed and has been moved
    to the ``meta-gnome`` layer.

 -  ``gnome-mime-data``: Recipe is no longer needed and has been moved to
    the ``meta-gnome`` layer.

 -  ``udev``: Replaced by the ``eudev`` recipe for compatibility when
    using ``sysvinit`` with newer kernels.

 -  ``python-pygtk``: Recipe became obsolete.

 -  ``adt-installer``: Recipe became obsolete. See the
    ":ref:`ref-manual/migration-2.1:adt removed`" section for more information.

 .. _migration-2.1-class-changes:

 Class Changes
 -------------

 The following classes have changed:

 -  ``autotools_stage``: Removed because the
    :ref:`autotools <ref-classes-autotools>` class now provides its
    functionality. Recipes that inherited from ``autotools_stage`` should
    now inherit from ``autotools`` instead.

 -  ``boot-directdisk``: Merged into the ``image-vm`` class. The
    ``boot-directdisk`` class was rarely directly used. Consequently,
    this change should not cause any issues.

 -  ``bootimg``: Merged into the
    :ref:`image-live <ref-classes-image-live>` class. The ``bootimg``
    class was rarely directly used. Consequently, this change should not
    cause any issues.

 -  ``packageinfo``: Removed due to its limited use by the Hob UI, which
    has itself been removed.

 .. _migration-2.1-build-system-ui-changes:

 Build System User Interface Changes
 -----------------------------------

 The following changes have been made to the build system user interface:

 -  *Hob GTK+-based UI*: Removed because it is unmaintained and based on
    the outdated GTK+ 2 library. The Toaster web-based UI is much more
    capable and is actively maintained. See the
    ":ref:`toaster-manual/setup-and-use:using the toaster web interface`"
    section in the Toaster User Manual for more information on this
    interface.

 -  *"puccho" BitBake UI*: Removed because is unmaintained and no longer
    useful.

 .. _migration-2.1-adt-removed:

 ADT Removed
 -----------

 The Application Development Toolkit (ADT) has been removed because its
 functionality almost completely overlapped with the :ref:`standard
 SDK <sdk-manual/using:using the standard sdk>` and the
 :ref:`extensible SDK <sdk-manual/extensible:using the extensible sdk>`. For
 information on these SDKs and how to build and use them, see the
 :doc:`/sdk-manual/index` manual.

 .. note::

    The Yocto Project Eclipse IDE Plug-in is still supported and is not
    affected by this change.

 .. _migration-2.1-poky-reference-distribution-changes:

 Poky Reference Distribution Changes
 -----------------------------------

 The following changes have been made for the Poky distribution:

 -  The ``meta-yocto`` layer has been renamed to ``meta-poky`` to better
    match its purpose, which is to provide the Poky reference
    distribution. The ``meta-yocto-bsp`` layer retains its original name
    since it provides reference machines for the Yocto Project and it is
    otherwise unrelated to Poky. References to ``meta-yocto`` in your
    ``conf/bblayers.conf`` should automatically be updated, so you should
    not need to change anything unless you are relying on this naming
    elsewhere.

 -  The :ref:`uninative <ref-classes-uninative>` class is now enabled
    by default in Poky. This class attempts to isolate the build system
    from the host distribution's C library and makes re-use of native
    shared state artifacts across different host distributions practical.
    With this class enabled, a tarball containing a pre-built C library
    is downloaded at the start of the build.

    The ``uninative`` class is enabled through the
    ``meta/conf/distro/include/yocto-uninative.inc`` file, which for
    those not using the Poky distribution, can include to easily enable
    the same functionality.

    Alternatively, if you wish to build your own ``uninative`` tarball,
    you can do so by building the ``uninative-tarball`` recipe, making it
    available to your build machines (e.g. over HTTP/HTTPS) and setting a
    similar configuration as the one set by ``yocto-uninative.inc``.

 -  Static library generation, for most cases, is now disabled by default
    in the Poky distribution. Disabling this generation saves some build
    time as well as the size used for build output artifacts.

    Disabling this library generation is accomplished through a
    ``meta/conf/distro/include/no-static-libs.inc``, which for those not
    using the Poky distribution can easily include to enable the same
    functionality.

    Any recipe that needs to opt-out of having the "--disable-static"
    option specified on the configure command line either because it is
    not a supported option for the configure script or because static
    libraries are needed should set the following variable:
    ::

       DISABLE_STATIC = ""

 -  The separate ``poky-tiny`` distribution now uses the musl C library
    instead of a heavily pared down ``glibc``. Using musl results in a
    smaller distribution and facilitates much greater maintainability
    because musl is designed to have a small footprint.

    If you have used ``poky-tiny`` and have customized the ``glibc``
    configuration you will need to redo those customizations with musl
    when upgrading to the new release.

 .. _migration-2.1-packaging-changes:

 Packaging Changes
 -----------------

 The following changes have been made to packaging:

 -  The ``runuser`` and ``mountpoint`` binaries, which were previously in
    the main ``util-linux`` package, have been split out into the
    ``util-linux-runuser`` and ``util-linux-mountpoint`` packages,
    respectively.

 -  The ``python-elementtree`` package has been merged into the
    ``python-xml`` package.

 .. _migration-2.1-tuning-file-changes:

 Tuning File Changes
 -------------------

 The following changes have been made to the tuning files:

 -  The "no-thumb-interwork" tuning feature has been dropped from the ARM
    tune include files. Because interworking is required for ARM EABI,
    attempting to disable it through a tuning feature no longer makes
    sense.

    .. note::

       Support for ARM OABI was deprecated in gcc 4.7.

 -  The ``tune-cortexm*.inc`` and ``tune-cortexr4.inc`` files have been
    removed because they are poorly tested. Until the OpenEmbedded build
    system officially gains support for CPUs without an MMU, these tuning
    files would probably be better maintained in a separate layer if
    needed.

 .. _migration-2.1-supporting-gobject-introspection:

 Supporting GObject Introspection
 --------------------------------

 This release supports generation of GLib Introspective Repository (GIR)
 files through GObject introspection, which is the standard mechanism for
 accessing GObject-based software from runtime environments. You can
 enable, disable, and test the generation of this data. See the
 ":ref:`dev-manual/common-tasks:enabling gobject introspection support`"
 section in the Yocto Project Development Tasks Manual for more
 information.

 .. _migration-2.1-miscellaneous-changes:

 Miscellaneous Changes
 ---------------------

 These additional changes exist:

 -  The minimum Git version has been increased to 1.8.3.1. If your host
    distribution does not provide a sufficiently recent version, you can
    install the buildtools, which will provide it. See the
    :ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
    section for more information on the buildtools tarball.

 -  The buggy and incomplete support for the RPM version 4 package
    manager has been removed. The well-tested and maintained support for
    RPM version 5 remains.

 -  Previously, the following list of packages were removed if
    package-management was not in
    :term:`IMAGE_FEATURES`, regardless of any
    dependencies:
    ::

       update-rc.d
       base-passwd
       shadow
       update-alternatives
       run-postinsts

    With the Yocto Project 2.1 release, these packages are
    only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since
    they might still be needed for a read-write image even in the absence
    of a package manager (e.g. if users need to be added, modified, or
    removed at runtime).

 -  The
    :ref:`devtool modify <sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
    command now defaults to extracting the source since that is most
    commonly expected. The "-x" or "--extract" options are now no-ops. If
    you wish to provide your own existing source tree, you will now need
    to specify either the "-n" or "--no-extract" options when running
    ``devtool modify``.

 -  If the formfactor for a machine is either not supplied or does not
    specify whether a keyboard is attached, then the default is to assume
    a keyboard is attached rather than assume no keyboard. This change
    primarily affects the Sato UI.

 -  The ``.debug`` directory packaging is now automatic. If your recipe
    builds software that installs binaries into directories other than
    the standard ones, you no longer need to take care of setting
    ``FILES_${PN}-dbg`` to pick up the resulting ``.debug`` directories
    as these directories are automatically found and added.

 -  Inaccurate disk and CPU percentage data has been dropped from
    ``buildstats`` output. This data has been replaced with
    ``getrusage()`` data and corrected IO statistics. You will probably
    need to update any custom code that reads the ``buildstats`` data.

 -  The ``meta/conf/distro/include/package_regex.inc`` is now deprecated.
    The contents of this file have been moved to individual recipes.

    .. note::

       Because this file will likely be removed in a future Yocto Project
       release, it is suggested that you remove any references to the
       file that might be in your configuration.

 -  The ``v86d/uvesafb`` has been removed from the ``genericx86`` and
    ``genericx86-64`` reference machines, which are provided by the
    ``meta-yocto-bsp`` layer. Most modern x86 boards do not rely on this
    file and it only adds kernel error messages during startup. If you do
    still need to support ``uvesafb``, you can simply add ``v86d`` to
    your image.

 -  Build sysroot paths are now removed from debug symbol files. Removing
    these paths means that remote GDB using an unstripped build system
    sysroot will no longer work (although this was never documented to
    work). The supported method to accomplish something similar is to set
    ``IMAGE_GEN_DEBUGFS`` to "1", which will generate a companion debug
    image containing unstripped binaries and associated debug sources
    alongside the image.
	Moving to the Yocto Project 2.1 Release (krogoth)
	=================================================

	This section provides migration information for moving to the Yocto
	Project 2.1 Release (codename "krogoth") from the prior release.

	.. _migration-2.1-variable-expansion-in-python-functions:

	Variable Expansion in Python Functions
	--------------------------------------

	Variable expressions, such as ``${VARNAME}`` no longer expand
	automatically within Python functions. Suppressing expansion was done to
	allow Python functions to construct shell scripts or other code for
	situations in which you do not want such expressions expanded. For any
	existing code that relies on these expansions, you need to change the
	expansions to expand the value of individual variables through
	``d.getVar()``. To alternatively expand more complex expressions, use
	``d.expand()``.

	.. _migration-2.1-overrides-must-now-be-lower-case:

	Overrides Must Now be Lower-Case
	--------------------------------

	The convention for overrides has always been for them to be lower-case
	characters. This practice is now a requirement as BitBake's datastore
	now assumes lower-case characters in order to give a slight performance
	boost during parsing. In practical terms, this requirement means that
	anything that ends up in :term:`OVERRIDES` must now
	appear in lower-case characters (e.g. values for ``MACHINE``,
	``TARGET_ARCH``, ``DISTRO``, and also recipe names if
	``_pn-``\ recipename overrides are to be effective).

	.. _migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory:

	Expand Parameter to ``getVar()`` and ``getVarFlag()`` is Now Mandatory
	----------------------------------------------------------------------

	The expand parameter to ``getVar()`` and ``getVarFlag()`` previously
	defaulted to False if not specified. Now, however, no default exists so
	one must be specified. You must change any ``getVar()`` calls that do
	not specify the final expand parameter to calls that do specify the
	parameter. You can run the following ``sed`` command at the base of a
	layer to make this change:
	::

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

	.. note::

	The reason for this change is that it prepares the way for changing
	the default to True in a future Yocto Project release. This future
	change is a much more sensible default than False. However, the
	change needs to be made gradually as a sudden change of the default
	would potentially cause side-effects that would be difficult to
	detect.

	.. _migration-2.1-makefile-environment-changes:

	Makefile Environment Changes
	----------------------------

	:term:`EXTRA_OEMAKE` now defaults to "" instead of
	"-e MAKEFLAGS=". Setting ``EXTRA_OEMAKE`` to "-e MAKEFLAGS=" by default
	was a historical accident that has required many classes (e.g.
	``autotools``, ``module``) and recipes to override this default in order
	to work with sensible build systems. When upgrading to the release, you
	must edit any recipe that relies upon this old default by either setting
	``EXTRA_OEMAKE`` back to "-e MAKEFLAGS=" or by explicitly setting any
	required variable value overrides using ``EXTRA_OEMAKE``, which is
	typically only needed when a Makefile sets a default value for a
	variable that is inappropriate for cross-compilation using the "="
	operator rather than the "?=" operator.

	.. _migration-2.1-libexecdir-reverted-to-prefix-libexec:

	``libexecdir`` Reverted to ``${prefix}/libexec``
	------------------------------------------------

	The use of ``${libdir}/${BPN}`` as ``libexecdir`` is different as
	compared to all other mainstream distributions, which either uses
	``${prefix}/libexec`` or ``${libdir}``. The use is also contrary to the
	GNU Coding Standards (i.e.
	https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
	that suggest ``${prefix}/libexec`` and also notes that any
	package-specific nesting should be done by the package itself. Finally,
	having ``libexecdir`` change between recipes makes it very difficult for
	different recipes to invoke binaries that have been installed into
	``libexecdir``. The Filesystem Hierarchy Standard (i.e.
	https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) now
	recognizes the use of ``${prefix}/libexec/``, giving distributions the
	choice between ``${prefix}/lib`` or ``${prefix}/libexec`` without
	breaking FHS.

	.. _migration-2.1-ac-cv-sizeof-off-t-no-longer-cached-in-site-files:

	``ac_cv_sizeof_off_t`` is No Longer Cached in Site Files
	--------------------------------------------------------

	For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
	class, ``ac_cv_sizeof_off_t`` is no longer cached in the site files for
	``autoconf``. The reason for this change is because the
	``ac_cv_sizeof_off_t`` value is not necessarily static per architecture
	as was previously assumed. Rather, the value changes based on whether
	large file support is enabled. For most software that uses ``autoconf``,
	this change should not be a problem. However, if you have a recipe that
	bypasses the standard :ref:`ref-tasks-configure` task
	from the ``autotools`` class and the software the recipe is building
	uses a very old version of ``autoconf``, the recipe might be incapable
	of determining the correct size of ``off_t`` during ``do_configure``.

	The best course of action is to patch the software as necessary to allow
	the default implementation from the ``autotools`` class to work such
	that ``autoreconf`` succeeds and produces a working configure script,
	and to remove the overridden ``do_configure`` task such that the default
	implementation does get used.

	.. _migration-2.1-image-generation-split-out-from-filesystem-generation:

	Image Generation is Now Split Out from Filesystem Generation
	------------------------------------------------------------

	Previously, for image recipes the :ref:`ref-tasks-rootfs`
	task assembled the filesystem and then from that filesystem generated
	images. With this Yocto Project release, image generation is split into
	separate :ref:`ref-tasks-image` tasks for clarity both in
	operation and in the code.

	For most cases, this change does not present any problems. However, if
	you have made customizations that directly modify the ``do_rootfs`` task
	or that mention ``do_rootfs``, you might need to update those changes.
	In particular, if you had added any tasks after ``do_rootfs``, you
	should make edits so that those tasks are after the
	:ref:`ref-tasks-image-complete` task rather than
	after ``do_rootfs`` so that your added tasks run at the correct
	time.

	A minor part of this restructuring is that the post-processing
	definitions and functions have been moved from the
	:ref:`image <ref-classes-image>` class to the
	:ref:`rootfs-postcommands <ref-classes-rootfs*>` class. Functionally,
	however, they remain unchanged.

	.. _migration-2.1-removed-recipes:

	Removed Recipes
	---------------

	The following recipes have been removed in the 2.1 release:

	- ``gcc`` version 4.8: Versions 4.9 and 5.3 remain.

	- ``qt4``: All support for Qt 4.x has been moved out to a separate
	``meta-qt4`` layer because Qt 4 is no longer supported upstream.

	- ``x11vnc``: Moved to the ``meta-oe`` layer.

	- ``linux-yocto-3.14``: No longer supported.

	- ``linux-yocto-3.19``: No longer supported.

	- ``libjpeg``: Replaced by the ``libjpeg-turbo`` recipe.

	- ``pth``: Became obsolete.

	- ``liboil``: Recipe is no longer needed and has been moved to the
	``meta-multimedia`` layer.

	- ``gtk-theme-torturer``: Recipe is no longer needed and has been moved
	to the ``meta-gnome`` layer.

	- ``gnome-mime-data``: Recipe is no longer needed and has been moved to
	the ``meta-gnome`` layer.

	- ``udev``: Replaced by the ``eudev`` recipe for compatibility when
	using ``sysvinit`` with newer kernels.

	- ``python-pygtk``: Recipe became obsolete.

	- ``adt-installer``: Recipe became obsolete. See the
	":ref:`ref-manual/migration-2.1:adt removed`" section for more information.

	.. _migration-2.1-class-changes:

	Class Changes
	-------------

	The following classes have changed:

	- ``autotools_stage``: Removed because the
	:ref:`autotools <ref-classes-autotools>` class now provides its
	functionality. Recipes that inherited from ``autotools_stage`` should
	now inherit from ``autotools`` instead.

	- ``boot-directdisk``: Merged into the ``image-vm`` class. The
	``boot-directdisk`` class was rarely directly used. Consequently,
	this change should not cause any issues.

	- ``bootimg``: Merged into the
	:ref:`image-live <ref-classes-image-live>` class. The ``bootimg``
	class was rarely directly used. Consequently, this change should not
	cause any issues.

	- ``packageinfo``: Removed due to its limited use by the Hob UI, which
	has itself been removed.

	.. _migration-2.1-build-system-ui-changes:

	Build System User Interface Changes
	-----------------------------------

	The following changes have been made to the build system user interface:

	- Hob GTK+-based UI: Removed because it is unmaintained and based on
	the outdated GTK+ 2 library. The Toaster web-based UI is much more
	capable and is actively maintained. See the
	":ref:`toaster-manual/setup-and-use:using the toaster web interface`"
	section in the Toaster User Manual for more information on this
	interface.

	- "puccho" BitBake UI: Removed because is unmaintained and no longer
	useful.

	.. _migration-2.1-adt-removed:

	ADT Removed
	-----------

	The Application Development Toolkit (ADT) has been removed because its
	functionality almost completely overlapped with the :ref:`standard
	SDK <sdk-manual/using:using the standard sdk>` and the
	:ref:`extensible SDK <sdk-manual/extensible:using the extensible sdk>`. For
	information on these SDKs and how to build and use them, see the
	:doc:`/sdk-manual/index` manual.

	.. note::

	The Yocto Project Eclipse IDE Plug-in is still supported and is not
	affected by this change.

	.. _migration-2.1-poky-reference-distribution-changes:

	Poky Reference Distribution Changes
	-----------------------------------

	The following changes have been made for the Poky distribution:

	- The ``meta-yocto`` layer has been renamed to ``meta-poky`` to better
	match its purpose, which is to provide the Poky reference
	distribution. The ``meta-yocto-bsp`` layer retains its original name
	since it provides reference machines for the Yocto Project and it is
	otherwise unrelated to Poky. References to ``meta-yocto`` in your
	``conf/bblayers.conf`` should automatically be updated, so you should
	not need to change anything unless you are relying on this naming
	elsewhere.

	- The :ref:`uninative <ref-classes-uninative>` class is now enabled
	by default in Poky. This class attempts to isolate the build system
	from the host distribution's C library and makes re-use of native
	shared state artifacts across different host distributions practical.
	With this class enabled, a tarball containing a pre-built C library
	is downloaded at the start of the build.

	The ``uninative`` class is enabled through the
	``meta/conf/distro/include/yocto-uninative.inc`` file, which for
	those not using the Poky distribution, can include to easily enable
	the same functionality.

	Alternatively, if you wish to build your own ``uninative`` tarball,
	you can do so by building the ``uninative-tarball`` recipe, making it
	available to your build machines (e.g. over HTTP/HTTPS) and setting a
	similar configuration as the one set by ``yocto-uninative.inc``.

	- Static library generation, for most cases, is now disabled by default
	in the Poky distribution. Disabling this generation saves some build
	time as well as the size used for build output artifacts.

	Disabling this library generation is accomplished through a
	``meta/conf/distro/include/no-static-libs.inc``, which for those not
	using the Poky distribution can easily include to enable the same
	functionality.

	Any recipe that needs to opt-out of having the "--disable-static"
	option specified on the configure command line either because it is
	not a supported option for the configure script or because static
	libraries are needed should set the following variable:
	::

	DISABLE_STATIC = ""

	- The separate ``poky-tiny`` distribution now uses the musl C library
	instead of a heavily pared down ``glibc``. Using musl results in a
	smaller distribution and facilitates much greater maintainability
	because musl is designed to have a small footprint.

	If you have used ``poky-tiny`` and have customized the ``glibc``
	configuration you will need to redo those customizations with musl
	when upgrading to the new release.

	.. _migration-2.1-packaging-changes:

	Packaging Changes
	-----------------

	The following changes have been made to packaging:

	- The ``runuser`` and ``mountpoint`` binaries, which were previously in
	the main ``util-linux`` package, have been split out into the
	``util-linux-runuser`` and ``util-linux-mountpoint`` packages,
	respectively.

	- The ``python-elementtree`` package has been merged into the
	``python-xml`` package.

	.. _migration-2.1-tuning-file-changes:

	Tuning File Changes
	-------------------

	The following changes have been made to the tuning files:

	- The "no-thumb-interwork" tuning feature has been dropped from the ARM
	tune include files. Because interworking is required for ARM EABI,
	attempting to disable it through a tuning feature no longer makes
	sense.

	.. note::

	Support for ARM OABI was deprecated in gcc 4.7.

	- The ``tune-cortexm*.inc`` and ``tune-cortexr4.inc`` files have been
	removed because they are poorly tested. Until the OpenEmbedded build
	system officially gains support for CPUs without an MMU, these tuning
	files would probably be better maintained in a separate layer if
	needed.

	.. _migration-2.1-supporting-gobject-introspection:

	Supporting GObject Introspection
	--------------------------------

	This release supports generation of GLib Introspective Repository (GIR)
	files through GObject introspection, which is the standard mechanism for
	accessing GObject-based software from runtime environments. You can
	enable, disable, and test the generation of this data. See the
	":ref:`dev-manual/common-tasks:enabling gobject introspection support`"
	section in the Yocto Project Development Tasks Manual for more
	information.

	.. _migration-2.1-miscellaneous-changes:

	Miscellaneous Changes
	---------------------

	These additional changes exist:

	- The minimum Git version has been increased to 1.8.3.1. If your host
	distribution does not provide a sufficiently recent version, you can
	install the buildtools, which will provide it. See the
	:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
	section for more information on the buildtools tarball.

	- The buggy and incomplete support for the RPM version 4 package
	manager has been removed. The well-tested and maintained support for
	RPM version 5 remains.

	- Previously, the following list of packages were removed if
	package-management was not in
	:term:`IMAGE_FEATURES`, regardless of any
	dependencies:
	::

	update-rc.d
	base-passwd
	shadow
	update-alternatives
	run-postinsts

	With the Yocto Project 2.1 release, these packages are
	only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since
	they might still be needed for a read-write image even in the absence
	of a package manager (e.g. if users need to be added, modified, or
	removed at runtime).

	- The
	:ref:`devtool modify <sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
	command now defaults to extracting the source since that is most
	commonly expected. The "-x" or "--extract" options are now no-ops. If
	you wish to provide your own existing source tree, you will now need
	to specify either the "-n" or "--no-extract" options when running
	``devtool modify``.

	- If the formfactor for a machine is either not supplied or does not
	specify whether a keyboard is attached, then the default is to assume
	a keyboard is attached rather than assume no keyboard. This change
	primarily affects the Sato UI.

	- The ``.debug`` directory packaging is now automatic. If your recipe
	builds software that installs binaries into directories other than
	the standard ones, you no longer need to take care of setting
	``FILES_${PN}-dbg`` to pick up the resulting ``.debug`` directories
	as these directories are automatically found and added.

	- Inaccurate disk and CPU percentage data has been dropped from
	``buildstats`` output. This data has been replaced with
	``getrusage()`` data and corrected IO statistics. You will probably
	need to update any custom code that reads the ``buildstats`` data.

	- The ``meta/conf/distro/include/package_regex.inc`` is now deprecated.
	The contents of this file have been moved to individual recipes.

	.. note::

	Because this file will likely be removed in a future Yocto Project
	release, it is suggested that you remove any references to the
	file that might be in your configuration.

	- The ``v86d/uvesafb`` has been removed from the ``genericx86`` and
	``genericx86-64`` reference machines, which are provided by the
	``meta-yocto-bsp`` layer. Most modern x86 boards do not rely on this
	file and it only adds kernel error messages during startup. If you do
	still need to support ``uvesafb``, you can simply add ``v86d`` to
	your image.

	- Build sysroot paths are now removed from debug symbol files. Removing
	these paths means that remote GDB using an unstripped build system
	sysroot will no longer work (although this was never documented to
	work). The supported method to accomplish something similar is to set
	``IMAGE_GEN_DEBUGFS`` to "1", which will generate a companion debug
	image containing unstripped binaries and associated debug sources
	alongside the image.