16 files changed, 4886 insertions, 3439 deletions

diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index e25f0b278c..04066e9202 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -4,9 +4,9 @@
 FAQ
 ***
 
-**Q:** How does Poky differ from `OpenEmbedded <&OE_HOME_URL;>`__?
+**Q:** How does Poky differ from `OpenEmbedded <http://www.openembedded.org/>`__?
 
-**A:** The term "`Poky <#>`__" refers to the specific reference build
+**A:** The term ``Poky`` refers to the specific reference build
 system that the Yocto Project provides. Poky is based on
 :term:`OpenEmbedded-Core (OE-Core)` and :term:`BitBake`. Thus, the
 generic term used here for the build system is the "OpenEmbedded build
@@ -44,11 +44,10 @@ steps on how to update your build tools.
 
 **A:** Support for an additional board is added by creating a Board
 Support Package (BSP) layer for it. For more information on how to
-create a BSP layer, see the "`Understanding and Creating
-Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__"
-section in the Yocto Project Development Tasks Manual and the `Yocto
-Project Board Support Package (BSP) Developer's
-Guide <&YOCTO_DOCS_BSP_URL;>`__.
+create a BSP layer, see the
+":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+section in the Yocto Project Development Tasks Manual and the
+:doc:`../bsp-guide/bsp-guide`.
 
 Usually, if the board is not completely exotic, adding support in the
 Yocto Project is fairly straightforward.
@@ -73,8 +72,8 @@ device.
 **Q:** How do I add my package to the Yocto Project?
 
 **A:** To add a package, you need to create a BitBake recipe. For
-information on how to create a BitBake recipe, see the "`Writing a New
-Recipe <&YOCTO_DOCS_DEV_URL;#new-recipe-writing-a-new-recipe>`__"
+information on how to create a BitBake recipe, see the
+":ref:`dev-manual/dev-manual-common-tasks:writing a new recipe`"
 section in the Yocto Project Development Tasks Manual.
 
 **Q:** Do I have to reflash my entire board with a new Yocto Project
@@ -126,12 +125,18 @@ file.
 
 Following is the applicable code for setting various proxy types in the
 ``.wgetrc`` file. By default, these settings are disabled with comments.
-To use them, remove the comments: # You can set the default proxies for
-Wget to use for http, https, and ftp. # They will override the value in
-the environment. #https_proxy = http://proxy.yoyodyne.com:18023/
-#http_proxy = http://proxy.yoyodyne.com:18023/ #ftp_proxy =
-http://proxy.yoyodyne.com:18023/ # If you do not want to use proxy at
-all, set this to off. #use_proxy = on The Yocto Project also includes a
+To use them, remove the comments: ::
+
+   # You can set the default proxies for Wget to use for http, https, and ftp.
+   # They will override the value in the environment.
+   #https_proxy = http://proxy.yoyodyne.com:18023/
+   #http_proxy = http://proxy.yoyodyne.com:18023/
+   #ftp_proxy = http://proxy.yoyodyne.com:18023/
+
+   # If you do not want to use proxy at all, set this to off.
+   #use_proxy = on
+
+The Yocto Project also includes a
 ``meta-poky/conf/site.conf.sample`` file that shows how to configure CVS
 and Git proxy servers if needed. For more information on setting up
 various proxy types and configuring proxy servers, see the
@@ -167,8 +172,12 @@ always been traced back to hardware or virtualization issues.
 **A:** If you get an error message that indicates GNU ``libiconv`` is
 not in use but ``iconv.h`` has been included from ``libiconv``, you need
 to check to see if you have a previously installed version of the header
-file in ``/usr/local/include``. #error GNU libiconv not in use but
-included iconv.h is from libiconv If you find a previously installed
+file in ``/usr/local/include``.
+::
+
+   #error GNU libiconv not in use but included iconv.h is from libiconv
+
+If you find a previously installed
 file, you should either uninstall it or temporarily rename it and try
 the build again.
 
@@ -189,20 +198,21 @@ and also any configuration information about how that package was
 configured and built.
 
 You can find more information on licensing in the
-"`Licensing <&YOCTO_DOCS_OM_URL;#licensing>`__" section in the Yocto
-Project Overview and Concepts Manual and also in the "`Maintaining Open
-Source License Compliance During Your Product's
-Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__"
+":ref:`overview-manual/overview-manual-development-environment:licensing`"
+section in the Yocto
+Project Overview and Concepts Manual and also in the
+":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
 **Q:** How do I disable the cursor on my touchscreen device?
 
 **A:** You need to create a form factor file as described in the
-"`Miscellaneous BSP-Specific Recipe
-Files <&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes>`__" section in
+":ref:`bsp-filelayout-misc-recipes`" section in
 the Yocto Project Board Support Packages (BSP) Developer's Guide. Set
 the ``HAVE_TOUCHSCREEN`` variable equal to one as follows:
-HAVE_TOUCHSCREEN=1
+::
+
+   HAVE_TOUCHSCREEN=1
 
 **Q:** How do I make sure connected network interfaces are brought up by
 default?
@@ -210,14 +220,14 @@ default?
 **A:** The default interfaces file provided by the netbase recipe does
 not automatically bring up network interfaces. Therefore, you will need
 to add a BSP-specific netbase that includes an interfaces file. See the
-"`Miscellaneous BSP-Specific Recipe
-Files <&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes>`__" section in
+":ref:`bsp-filelayout-misc-recipes`" section in
 the Yocto Project Board Support Packages (BSP) Developer's Guide for
 information on creating these types of miscellaneous recipe files.
 
-For example, add the following files to your layer:
-meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
-meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
+For example, add the following files to your layer: ::
+
+   meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
+   meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
 
 **Q:** How do I create images with more free space?
 
@@ -260,7 +270,7 @@ controls which ``tcmode-*.inc`` file to include from the
 The default value of ``TCMODE`` is "default", which tells the
 OpenEmbedded build system to use its internally built toolchain (i.e.
 ``tcmode-default.inc``). However, other patterns are accepted. In
-particular, "external-*" refers to external toolchains. One example is
+particular, "external-\*" refers to external toolchains. One example is
 the Sourcery G++ Toolchain. The support for this toolchain resides in
 the separate ``meta-sourcery`` layer at
 http://github.com/MentorEmbedded/meta-sourcery/.
@@ -290,11 +300,13 @@ fail.
 
 As an example, you could add a specific server for the build system to
 attempt before any others by adding something like the following to the
-``local.conf`` configuration file: PREMIRRORS_prepend = "\\ git://.*/.\*
-http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\*
-http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\*
-http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\*
-http://www.yoctoproject.org/sources/ \\n"
+``local.conf`` configuration file: ::
+
+   PREMIRRORS_prepend = "\
+       git://.*/.* http://www.yoctoproject.org/sources/ \n \
+       ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+       http://.*/.* http://www.yoctoproject.org/sources/ \n \
+       https://.*/.* http://www.yoctoproject.org/sources/ \n"
 
 These changes cause the build system to intercept Git, FTP, HTTP, and
 HTTPS requests and direct them to the ``http://`` sources mirror. You
@@ -302,25 +314,43 @@ can use ``file://`` URLs to point to local directories or network shares
 as well.
 
 Aside from the previous technique, these options also exist:
-BB_NO_NETWORK = "1" This statement tells BitBake to issue an error
+::
+
+   BB_NO_NETWORK = "1"
+
+This statement tells BitBake to issue an error
 instead of trying to access the Internet. This technique is useful if
 you want to ensure code builds only from local sources.
 
-Here is another technique: BB_FETCH_PREMIRRORONLY = "1" This statement
+Here is another technique:
+::
+
+   BB_FETCH_PREMIRRORONLY = "1"
+
+This statement
 limits the build system to pulling source from the ``PREMIRRORS`` only.
 Again, this technique is useful for reproducing builds.
 
-Here is another technique: BB_GENERATE_MIRROR_TARBALLS = "1" This
+Here is another technique:
+::
+
+   BB_GENERATE_MIRROR_TARBALLS = "1"
+
+This
 statement tells the build system to generate mirror tarballs. This
 technique is useful if you want to create a mirror server. If not,
 however, the technique can simply waste time during the build.
 
 Finally, consider an example where you are behind an HTTP-only firewall.
 You could make the following changes to the ``local.conf`` configuration
-file as long as the ``PREMIRRORS`` server is current: PREMIRRORS_prepend
-= "\\ ftp://.*/.\* http://www.yoctoproject.org/sources/ \\n \\
-http://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\*
-http://www.yoctoproject.org/sources/ \\n" BB_FETCH_PREMIRRORONLY = "1"
+file as long as the ``PREMIRRORS`` server is current: ::
+
+   PREMIRRORS_prepend = "\
+       ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+       http://.*/.* http://www.yoctoproject.org/sources/ \n \
+       https://.*/.* http://www.yoctoproject.org/sources/ \n"
+   BB_FETCH_PREMIRRORONLY = "1"
+
 These changes would cause the build system to successfully fetch source
 over HTTP and any network accesses to anything other than the
 ``PREMIRRORS`` would fail.
@@ -384,18 +414,21 @@ that program is never installed directly to the build machine's root
 file system. Consequently, the build system uses paths within the Build
 Directory for ``DESTDIR``, ``bindir`` and related variables. To better
 understand this, consider the following two paths where the first is
-relatively normal and the second is not:
+relatively normal and the second is not: ::
+
+   /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/
+      1.2.8-r0/sysroot-destdir/usr/bin
+
+   /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/
+      zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/
+      build/tmp/sysroots/x86_64-linux/usr/bin
 
 .. note::
 
    Due to these lengthy examples, the paths are artificially broken
    across lines for readability.
 
-/home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/
-1.2.8-r0/sysroot-destdir/usr/bin
-/home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/
-zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/
-build/tmp/sysroots/x86_64-linux/usr/bin Even if the paths look unusual,
+Even if the paths look unusual,
 they both are correct - the first for a target and the second for a
 native recipe. These paths are a consequence of the ``DESTDIR``
 mechanism and while they appear strange, they are correct and in
diff --git a/documentation/ref-manual/migration.rst b/documentation/ref-manual/migration.rst
index f834ba7004..d0d8f47932 100644
--- a/documentation/ref-manual/migration.rst
+++ b/documentation/ref-manual/migration.rst
@@ -15,7 +15,9 @@ Some considerations are not tied to a specific Yocto Project release.
 This section presents information you should consider when migrating to
 any new Yocto Project release.
 
--  *Dealing with Customized Recipes*: Issues could arise if you take
+-  *Dealing with Customized Recipes*:
+
+   Issues could arise if you take
    older recipes that contain customizations and simply copy them
    forward expecting them to work after you migrate to new Yocto Project
    metadata. For example, suppose you have a recipe in your layer that
@@ -39,7 +41,9 @@ any new Yocto Project release.
    use an append file. A good example of this is when introducing a
    newer or older version of a recipe in another layer.
 
--  *Updating Append Files*: Since append files generally only contain
+-  *Updating Append Files*:
+
+   Since append files generally only contain
    your customizations, they often do not need to be adjusted for new
    releases. However, if the ``.bbappend`` file is specific to a
    particular version of the recipe (i.e. its name does not use the %
@@ -85,8 +89,9 @@ location (either local or remote) and then point to it in
 :term:`SSTATE_MIRRORS`, you need to append "PATH"
 to the end of the mirror URL so that the path used by BitBake before the
 mirror substitution is appended to the path used to access the mirror.
-Here is an example: SSTATE_MIRRORS = "file://.\*
-http://someserver.tld/share/sstate/PATH"
+Here is an example: ::
+
+   SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
 
 .. _migration-1.3-bblayers-conf:
 
@@ -107,18 +112,6 @@ Recipes
 
 Differences include changes for the following:
 
--  Python function whitespace
-
--  ``proto=`` in ``SRC_URI``
-
--  ``nativesdk``
-
--  Task recipes
-
--  ``IMAGE_FEATURES``
-
--  Removed recipes
-
 .. _migration-1.3-python-function-whitespace:
 
 Python Function Whitespace
@@ -205,26 +198,26 @@ unlikely that you would have any references to them in your own
 :term:`Metadata`. However, you should check your metadata
 against this list to be sure:
 
--  *``libx11-trim``*: Replaced by ``libx11``, which has a negligible
+-  ``libx11-trim``: Replaced by ``libx11``, which has a negligible
    size difference with modern Xorg.
 
--  *``xserver-xorg-lite``*: Use ``xserver-xorg``, which has a negligible
+-  ``xserver-xorg-lite``: Use ``xserver-xorg``, which has a negligible
    size difference when DRI and GLX modules are not installed.
 
--  *``xserver-kdrive``*: Effectively unmaintained for many years.
+-  ``xserver-kdrive``: Effectively unmaintained for many years.
 
--  *``mesa-xlib``*: No longer serves any purpose.
+-  ``mesa-xlib``: No longer serves any purpose.
 
--  *``galago``*: Replaced by telepathy.
+-  ``galago``: Replaced by telepathy.
 
--  *``gail``*: Functionality was integrated into GTK+ 2.13.
+-  ``gail``: Functionality was integrated into GTK+ 2.13.
 
--  *``eggdbus``*: No longer needed.
+-  ``eggdbus``: No longer needed.
 
--  *``gcc-*-intermediate``*: The build has been restructured to avoid
+-  ``gcc-*-intermediate``: The build has been restructured to avoid
    the need for this step.
 
--  *``libgsmd``*: Unmaintained for many years. Functionality now
+-  ``libgsmd``: Unmaintained for many years. Functionality now
    provided by ``ofono`` instead.
 
 -  *contacts, dates, tasks, eds-tools*: Largely unmaintained PIM
@@ -238,8 +231,9 @@ recipes were not parsed in the default configuration. Many of these
 recipes are already provided in an updated and maintained form within
 the OpenEmbedded community layers such as ``meta-oe`` and
 ``meta-gnome``. For the remainder, you can now find them in the
-``meta-extras`` repository, which is in the Yocto Project `Source
-Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__.
+``meta-extras`` repository, which is in the
+:yocto_git:`Source Repositories <>` at
+http://git.yoctoproject.org/cgit/cgit.cgi/meta-extras/.
 
 .. _1.3-linux-kernel-naming:
 
@@ -248,13 +242,15 @@ Linux Kernel Naming
 
 The naming scheme for kernel output binaries has been changed to now
 include :term:`PE` as part of the filename:
-KERNEL_IMAGE_BASE_NAME ?=
-"${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
+::
+
+   KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
 
 Because the ``PE`` variable is not set by default, these binary files
 could result with names that include two dash characters. Here is an
-example:
-bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin
+example: ::
+
+   bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin
 
 Moving to the Yocto Project 1.4 Release
 =======================================
@@ -298,8 +294,12 @@ Differences include the following:
 
 -  *Shared State Code:* The shared state code has been optimized to
    avoid running unnecessary tasks. For example, the following no longer
-   populates the target sysroot since that is not necessary: $ bitbake
-   -c rootfs some-image Instead, the system just needs to extract the
+   populates the target sysroot since that is not necessary:
+   ::
+
+      $ bitbake -c rootfs some-image
+
+   Instead, the system just needs to extract the
    output package contents, re-create the packages, and construct the
    root filesystem. This change is unlikely to cause any problems unless
    you have missing declared dependencies.
@@ -337,9 +337,9 @@ creating an append file for the ``netbase`` recipe, you now need to
 create an append file for the ``init-ifupdown`` recipe instead, which
 you can find in the :term:`Source Directory` at
 ``meta/recipes-core/init-ifupdown``. For information on how to use
-append files, see the "`Using .bbappend
-Files <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in the
-Yocto Project Development Tasks Manual.
+append files, see the
+":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.4-remote-debugging:
 
@@ -360,7 +360,7 @@ Variables
 
 The following variables have changed:
 
--  *``SANITY_TESTED_DISTROS``:* This variable now uses a distribution
+-  ``SANITY_TESTED_DISTROS``: This variable now uses a distribution
    ID, which is composed of the host distributor ID followed by the
    release. Previously,
    :term:`SANITY_TESTED_DISTROS` was
@@ -369,7 +369,7 @@ The following variables have changed:
    you are not specifically setting this variable, or if you are
    specifically setting it to "".
 
--  *``SRC_URI``:* The ``${``\ :term:`PN`\ ``}``,
+-  ``SRC_URI``: The ``${``\ :term:`PN`\ ``}``,
    ``${``\ :term:`PF`\ ``}``,
    ``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories
    have been dropped from the default value of the
@@ -390,7 +390,10 @@ Target Package Management with RPM
 If runtime package management is enabled and the RPM backend is
 selected, Smart is now installed for package download, dependency
 resolution, and upgrades instead of Zypper. For more information on how
-to use Smart, run the following command on the target: smart --help
+to use Smart, run the following command on the target:
+::
+
+   smart --help
 
 .. _migration-1.4-recipes-moved:
 
@@ -400,29 +403,29 @@ Recipes Moved
 The following recipes were moved from their previous locations because
 they are no longer used by anything in the OpenEmbedded-Core:
 
--  *``clutter-box2d``:* Now resides in the ``meta-oe`` layer.
+-  ``clutter-box2d``: Now resides in the ``meta-oe`` layer.
 
--  *``evolution-data-server``:* Now resides in the ``meta-gnome`` layer.
+-  ``evolution-data-server``: Now resides in the ``meta-gnome`` layer.
 
--  *``gthumb``:* Now resides in the ``meta-gnome`` layer.
+-  ``gthumb``: Now resides in the ``meta-gnome`` layer.
 
--  *``gtkhtml2``:* Now resides in the ``meta-oe`` layer.
+-  ``gtkhtml2``: Now resides in the ``meta-oe`` layer.
 
--  *``gupnp``:* Now resides in the ``meta-multimedia`` layer.
+-  ``gupnp``: Now resides in the ``meta-multimedia`` layer.
 
--  *``gypsy``:* Now resides in the ``meta-oe`` layer.
+-  ``gypsy``: Now resides in the ``meta-oe`` layer.
 
--  *``libcanberra``:* Now resides in the ``meta-gnome`` layer.
+-  ``libcanberra``: Now resides in the ``meta-gnome`` layer.
 
--  *``libgdata``:* Now resides in the ``meta-gnome`` layer.
+-  ``libgdata``: Now resides in the ``meta-gnome`` layer.
 
--  *``libmusicbrainz``:* Now resides in the ``meta-multimedia`` layer.
+-  ``libmusicbrainz``: Now resides in the ``meta-multimedia`` layer.
 
--  *``metacity``:* Now resides in the ``meta-gnome`` layer.
+-  ``metacity``: Now resides in the ``meta-gnome`` layer.
 
--  *``polkit``:* Now resides in the ``meta-oe`` layer.
+-  ``polkit``: Now resides in the ``meta-oe`` layer.
 
--  *``zeroconf``:* Now resides in the ``meta-networking`` layer.
+-  ``zeroconf``: Now resides in the ``meta-networking`` layer.
 
 .. _migration-1.4-removals-and-renames:
 
@@ -431,58 +434,58 @@ Removals and Renames
 
 The following list shows what has been removed or renamed:
 
--  *``evieext``:* Removed because it has been removed from ``xserver``
+-  ``evieext``: Removed because it has been removed from ``xserver``
    since 2008.
 
 -  *Gtk+ DirectFB:* Removed support because upstream Gtk+ no longer
    supports it as of version 2.18.
 
--  *``libxfontcache / xfontcacheproto``:* Removed because they were
+-  ``libxfontcache / xfontcacheproto``: Removed because they were
    removed from the Xorg server in 2008.
 
--  *``libxp / libxprintapputil / libxprintutil / printproto``:* Removed
+-  ``libxp / libxprintapputil / libxprintutil / printproto``: Removed
    because the XPrint server was removed from Xorg in 2008.
 
--  *``libxtrap / xtrapproto``:* Removed because their functionality was
+-  ``libxtrap / xtrapproto``: Removed because their functionality was
    broken upstream.
 
 -  *linux-yocto 3.0 kernel:* Removed with linux-yocto 3.8 kernel being
    added. The linux-yocto 3.2 and linux-yocto 3.4 kernels remain as part
    of the release.
 
--  *``lsbsetup``:* Removed with functionality now provided by
+-  ``lsbsetup``: Removed with functionality now provided by
    ``lsbtest``.
 
--  *``matchbox-stroke``:* Removed because it was never more than a
+-  ``matchbox-stroke``: Removed because it was never more than a
    proof-of-concept.
 
--  *``matchbox-wm-2 / matchbox-theme-sato-2``:* Removed because they are
+-  ``matchbox-wm-2 / matchbox-theme-sato-2``: Removed because they are
    not maintained. However, ``matchbox-wm`` and ``matchbox-theme-sato``
    are still provided.
 
--  *``mesa-dri``:* Renamed to ``mesa``.
+-  ``mesa-dri``: Renamed to ``mesa``.
 
--  *``mesa-xlib``:* Removed because it was no longer useful.
+-  ``mesa-xlib``: Removed because it was no longer useful.
 
--  *``mutter``:* Removed because nothing ever uses it and the recipe is
+-  ``mutter``: Removed because nothing ever uses it and the recipe is
    very old.
 
--  *``orinoco-conf``:* Removed because it has become obsolete.
+-  ``orinoco-conf``: Removed because it has become obsolete.
 
--  *``update-modules``:* Removed because it is no longer used. The
+-  ``update-modules``: Removed because it is no longer used. The
    kernel module ``postinstall`` and ``postrm`` scripts can now do the
    same task without the use of this script.
 
--  *``web``:* Removed because it is not maintained. Superseded by
+-  ``web``: Removed because it is not maintained. Superseded by
    ``web-webkit``.
 
--  *``xf86bigfontproto``:* Removed because upstream it has been disabled
+-  ``xf86bigfontproto``: Removed because upstream it has been disabled
    by default since 2007. Nothing uses ``xf86bigfontproto``.
 
--  *``xf86rushproto``:* Removed because its dependency in ``xserver``
+-  ``xf86rushproto``: Removed because its dependency in ``xserver``
    was spurious and it was removed in 2005.
 
--  *``zypper / libzypp / sat-solver``:* Removed and been functionally
+-  ``zypper / libzypp / sat-solver``: Removed and been functionally
    replaced with Smart (``python-smartpm``) when RPM packaging is used
    and package management is enabled on the target.
 
@@ -735,8 +738,7 @@ A new automated image testing framework has been added through the
 framework replaces the older ``imagetest-qemu`` framework.
 
 You can learn more about performing automated image tests in the
-"`Performing Automated Runtime
-Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.5-build-history:
@@ -758,9 +760,8 @@ Following are changes to Build History:
    utilities have improved command-line handling. Use the ``--help``
    option for each utility for more information on the new syntax.
 
-For more information on Build History, see the "`Maintaining Build
-Output
-Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__"
+For more information on Build History, see the
+":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.5-udev:
@@ -836,7 +837,7 @@ Following is a list of short entries describing other changes:
 
 -  ``image.bbclass``: Move ``runtime_mapping_rename`` to avoid conflict
    with ``multilib``. See
-   ```YOCTO #4993`https://bugzilla.yoctoproject.org/show_bug.cgi?id=4993
+   `YOCTO #4993 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=4993>`_
    in Bugzilla for more information.
 
 -  ``linux-dtb``: Use kernel build system to generate the ``dtb`` files.
@@ -856,9 +857,8 @@ Project 1.6 Release from the prior release.
 
 The :ref:`archiver <ref-classes-archiver>` class has been rewritten
 and its configuration has been simplified. For more details on the
-source archiver, see the "`Maintaining Open Source License Compliance
-During Your Product's
-Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__"
+source archiver, see the
+":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.6-packaging-changes:
@@ -992,9 +992,8 @@ NFS mount, an error occurs.
 The ``PRINC`` variable has been deprecated and triggers a warning if
 detected during a build. For :term:`PR` increments on changes,
 use the PR service instead. You can find out more about this service in
-the "`Working With a PR
-Service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__" section in
-the Yocto Project Development Tasks Manual.
+the ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`"
+section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.6-variable-changes-IMAGE_TYPES:
 
@@ -1039,19 +1038,25 @@ Preprocess and Post Process Command Variable Behavior
 
 The following variables now expect a semicolon separated list of
 functions to call and not arbitrary shell commands:
-:term:`ROOTFS_PREPROCESS_COMMAND`
-:term:`ROOTFS_POSTPROCESS_COMMAND`
-:term:`SDK_POSTPROCESS_COMMAND`
-:term:`POPULATE_SDK_POST_TARGET_COMMAND`
-:term:`POPULATE_SDK_POST_HOST_COMMAND`
-:term:`IMAGE_POSTPROCESS_COMMAND`
-:term:`IMAGE_PREPROCESS_COMMAND`
-:term:`ROOTFS_POSTUNINSTALL_COMMAND`
-:term:`ROOTFS_POSTINSTALL_COMMAND` For
+
+  - :term:`ROOTFS_PREPROCESS_COMMAND`
+  - :term:`ROOTFS_POSTPROCESS_COMMAND`
+  - :term:`SDK_POSTPROCESS_COMMAND`
+  - :term:`POPULATE_SDK_POST_TARGET_COMMAND`
+  - :term:`POPULATE_SDK_POST_HOST_COMMAND`
+  - :term:`IMAGE_POSTPROCESS_COMMAND`
+  - :term:`IMAGE_PREPROCESS_COMMAND`
+  - :term:`ROOTFS_POSTUNINSTALL_COMMAND`
+  - :term:`ROOTFS_POSTINSTALL_COMMAND`
+
+For
 migration purposes, you can simply wrap shell commands in a shell
-function and then call the function. Here is an example:
-my_postprocess_function() { echo "hello" > ${IMAGE_ROOTFS}/hello.txt }
-ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "
+function and then call the function. Here is an example: ::
+
+   my_postprocess_function() {
+      echo "hello" > ${IMAGE_ROOTFS}/hello.txt
+   }
+   ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "
 
 .. _migration-1.6-package-test-ptest:
 
@@ -1059,9 +1064,9 @@ Package Test (ptest)
 --------------------
 
 Package Tests (ptest) are built but not installed by default. For
-information on using Package Tests, see the "`Testing Packages with
-ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in
-the Yocto Project Development Tasks Manual. For information on the
+information on using Package Tests, see the
+":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+section in the Yocto Project Development Tasks Manual. For information on the
 ``ptest`` class, see the ":ref:`ptest.bbclass <ref-classes-ptest>`"
 section.
 
@@ -1087,8 +1092,11 @@ the ``autotools`` or ``autotools_stage``\ classes.
 
 ``qemu-native`` now builds without SDL-based graphical output support by
 default. The following additional lines are needed in your
-``local.conf`` to enable it: PACKAGECONFIG_pn-qemu-native = "sdl"
-ASSUME_PROVIDED += "libsdl-native"
+``local.conf`` to enable it:
+::
+
+   PACKAGECONFIG_pn-qemu-native = "sdl"
+   ASSUME_PROVIDED += "libsdl-native"
 
 .. note::
 
@@ -1270,15 +1278,18 @@ means that existing ``local.conf`` files will need to be be modified to
 append to ``PACKAGECONFIG`` for ``qemu-native`` and ``nativesdk-qemu``
 instead of setting it. In other words, to enable graphical output for
 QEMU, you should now have these lines in ``local.conf``:
-PACKAGECONFIG_append_pn-qemu-native = " sdl"
-PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
+::
+
+   PACKAGECONFIG_append_pn-qemu-native = " sdl"
+   PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
 
 .. _migration-1.7-minimum-git-version:
 
 Minimum Git version
 -------------------
 
-The minimum `Git <&YOCTO_DOCS_OM_URL;#git>`__ version required on the
+The minimum :ref:`overview-manual/overview-manual-development-environment:git`
+version required on the
 build host is now 1.7.8 because the ``--list`` option is now required by
 BitBake's Git fetcher. As always, if your host distribution does not
 provide a version of Git that meets this requirement, you can use the
@@ -1308,8 +1319,8 @@ occurred:
    the :ref:`autotools-brokensep <ref-classes-autotools>` class
    instead of the ``autotools`` or ``autotools_stage`` classes.
 
--  *The ``--foreign`` option is no longer passed to ``automake`` when
-   running ``autoconf``:* This option tells ``automake`` that a
+-  The ``--foreign`` option is no longer passed to ``automake`` when
+   running ``autoconf``: This option tells ``automake`` that a
    particular software package does not follow the GNU standards and
    therefore should not be expected to distribute certain files such as
    ``ChangeLog``, ``AUTHORS``, and so forth. Because the majority of
@@ -1331,15 +1342,31 @@ disable the scripts due to the scripts previously requiring error-prone
 path substitution. Software that links against these libraries using
 these scripts should use the much more robust ``pkg-config`` instead.
 The list of recipes changed in this version (and their configuration
-scripts) is as follows: directfb (directfb-config) freetype
-(freetype-config) gpgme (gpgme-config) libassuan (libassuan-config)
-libcroco (croco-6.0-config) libgcrypt (libgcrypt-config) libgpg-error
-(gpg-error-config) libksba (ksba-config) libpcap (pcap-config) libpcre
-(pcre-config) libpng (libpng-config, libpng16-config) libsdl
-(sdl-config) libusb-compat (libusb-config) libxml2 (xml2-config) libxslt
-(xslt-config) ncurses (ncurses-config) neon (neon-config) npth
-(npth-config) pth (pth-config) taglib (taglib-config) Additionally,
-support for ``pkg-config`` has been added to some recipes in the
+scripts) is as follows:
+::
+
+   directfb (directfb-config)
+   freetype (freetype-config)
+   gpgme (gpgme-config)
+   libassuan (libassuan-config)
+   libcroco (croco-6.0-config)
+   libgcrypt (libgcrypt-config)
+   libgpg-error (gpg-error-config)
+   libksba (ksba-config)
+   libpcap (pcap-config)
+   libpcre (pcre-config)
+   libpng (libpng-config, libpng16-config)
+   libsdl (sdl-config)
+   libusb-compat (libusb-config)
+   libxml2 (xml2-config)
+   libxslt (xslt-config)
+   ncurses (ncurses-config)
+   neon (neon-config)
+   npth (npth-config)
+   pth (pth-config)
+   taglib (taglib-config)
+
+Additionally, support for ``pkg-config`` has been added to some recipes in the
 previous list in the rare cases where the upstream software package does
 not already provide it.
 
@@ -1453,8 +1480,8 @@ The following miscellaneous change occurred:
    build header as printed by BitBake upon starting the build. You
    should manually remove old "build-id" files from your existing build
    history repositories to avoid confusion. For information on the build
-   history feature, see the "`Maintaining Build Output
-   Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__"
+   history feature, see the
+   ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
    section in the Yocto Project Development Tasks Manual.
 
 Moving to the Yocto Project 1.8 Release
@@ -1515,11 +1542,12 @@ you can now remove them.
 Additionally, a ``bluetooth`` class has been added to make selection of
 the appropriate bluetooth support within a recipe a little easier. If
 you wish to make use of this class in a recipe, add something such as
-the following: inherit bluetooth PACKAGECONFIG ??=
-"${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '',
-d)}" PACKAGECONFIG[bluez4] =
-"--enable-bluetooth,--disable-bluetooth,bluez4" PACKAGECONFIG[bluez5] =
-"--enable-bluez5,--disable-bluez5,bluez5"
+the following: ::
+
+   inherit bluetooth
+   PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
+   PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
+   PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
 
 .. _migration-1.8-kernel-build-changes:
 
@@ -1542,8 +1570,9 @@ where the ``linux.inc`` file in ``meta-oe`` was updated.
 
 Recipes that rely on the kernel source code and do not inherit the
 module classes might need to add explicit dependencies on the
-``do_shared_workdir`` kernel task, for example: do_configure[depends] +=
-"virtual/kernel:do_shared_workdir"
+``do_shared_workdir`` kernel task, for example: ::
+
+   do_configure[depends] += "virtual/kernel:do_shared_workdir"
 
 .. _migration-1.8-ssl:
 
@@ -1588,8 +1617,9 @@ One of the improvements is to attempt to run "make clean" during the
 ``do_configure`` task if a ``Makefile`` exists. Some software packages
 do not provide a working clean target within their make files. If you
 have such recipes, you need to set
-:term:`CLEANBROKEN` to "1" within the recipe, for
-example: CLEANBROKEN = "1"
+:term:`CLEANBROKEN` to "1" within the recipe, for example: ::
+
+   CLEANBROKEN = "1"
 
 .. _migration-1.8-qa-check-and-validation-changes:
 
@@ -1663,7 +1693,10 @@ and the porting guide at
 https://gcc.gnu.org/gcc-5/porting_to.html.
 
 Alternatively, you can switch back to GCC 4.9 or 4.8 by setting
-``GCCVERSION`` in your configuration, as follows: GCCVERSION = "4.9%"
+``GCCVERSION`` in your configuration, as follows:
+::
+
+   GCCVERSION = "4.9%"
 
 .. _migration-2.0-Gstreamer-0.10-removed:
 
@@ -1726,7 +1759,10 @@ unlikely to require any changes to Metadata. However, these minor
 changes in behavior exist:
 
 -  All potential overrides are now visible in the variable history as
-   seen when you run the following: $ bitbake -e
+   seen when you run the following:
+   ::
+
+      $ bitbake -e
 
 -  ``d.delVar('``\ VARNAME\ ``')`` and
    ``d.setVar('``\ VARNAME\ ``', None)`` result in the variable and all
@@ -1833,7 +1869,9 @@ changes.
 Additionally, work directories for old versions of recipes are now
 pruned. If you wish to disable pruning old work directories, you can set
 the following variable in your configuration:
-SSTATE_PRUNE_OBSOLETEWORKDIR = "0"
+::
+
+   SSTATE_PRUNE_OBSOLETEWORKDIR = "0"
 
 .. _migration-2.0-linux-yocto-kernel-metadata-repository-now-split-from-source:
 
@@ -1952,9 +1990,11 @@ 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 \*\`
+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::
 
@@ -2124,8 +2164,8 @@ 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 "`Using the Toaster Web
-   Interface <&YOCTO_DOCS_TOAST_URL;#using-the-toaster-web-interface>`__"
+   capable and is actively maintained. See the
+   ":ref:`toaster-manual/toaster-manual-setup-and-use:using the toaster web interface`"
    section in the Toaster User Manual for more information on this
    interface.
 
@@ -2138,12 +2178,11 @@ ADT Removed
 -----------
 
 The Application Development Toolkit (ADT) has been removed because its
-functionality almost completely overlapped with the `standard
-SDK <&YOCTO_DOCS_SDK_URL;#sdk-using-the-standard-sdk>`__ and the
-`extensible SDK <&YOCTO_DOCS_SDK_URL;#sdk-extensible>`__. For
-information on these SDKs and how to build and use them, see the `Yocto
-Project Application Development and the Extensible Software Development
-Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual.
+functionality almost completely overlapped with the :ref:`standard
+SDK <sdk-manual/sdk-using:using the standard sdk>` and the
+:ref:`extensible SDK <sdk-manual/sdk-extensible:using the extensible sdk>`. For
+information on these SDKs and how to build and use them, see the
+:doc:`../sdk-manual/sdk-manual` manual.
 
 .. note::
 
@@ -2253,8 +2292,7 @@ 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
-"`Enabling GObject Introspection
-Support <&YOCTO_DOCS_DEV_URL;#enabling-gobject-introspection-support>`__"
+":ref:`dev-manual/dev-manual-common-tasks:enabling gobject introspection support`"
 section in the Yocto Project Development Tasks Manual for more
 information.
 
@@ -2279,7 +2317,14 @@ These additional changes exist:
 -  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
+   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
@@ -2287,7 +2332,7 @@ These additional changes exist:
    removed at runtime).
 
 -  The
-   ```devtool modify`` <&YOCTO_DOCS_SDK_URL;#sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component>`__
+   :ref:`devtool modify <sdk-manual/sdk-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
@@ -2409,10 +2454,15 @@ The metadata is now required to use Python 3 syntax. For help preparing
 metadata, see any of the many Python 3 porting guides available.
 Alternatively, you can reference the conversion commits for Bitbake and
 you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are
-particular areas of interest: \* subprocess command-line pipes needing
-locale decoding \* the syntax for octal values changed \* the
-``iter*()`` functions changed name \* iterators now return views, not
-lists \* changed names for Python modules
+particular areas of interest:
+
+  - subprocess command-line pipes needing locale decoding
+
+  - the syntax for octal values changed
+
+  - the ``iter*()`` functions changed name \* iterators now return views, not lists
+
+  - changed names for Python modules
 
 .. _migration-2.2-target-python-recipes-switched-to-python-3:
 
@@ -2474,7 +2524,12 @@ The new ``runqemu`` is a Python script. Machine knowledge is no longer
 hardcoded into ``runqemu``. You can choose to use the ``qemuboot``
 configuration file to define the BSP's own arguments and to make it
 bootable with ``runqemu``. If you use a configuration file, use the
-following form: image-name-machine.qemuboot.conf The configuration file
+following form:
+::
+
+   image-name-machine.qemuboot.conf
+
+The configuration file
 enables fine-grained tuning of options passed to QEMU without the
 ``runqemu`` script hard-coding any knowledge about different machines.
 Using a configuration file is particularly convenient when trying to use
@@ -2485,14 +2540,28 @@ rootfs). QEMU boot arguments can be set in BSP's configuration file and
 the ``qemuboot`` class will save them to ``qemuboot.conf``.
 
 If you want to use ``runqemu`` without a configuration file, use the
-following command form: $ runqemu machine rootfs kernel [options]
-Supported machines are as follows: qemuarm qemuarm64 qemux86 qemux86-64
-qemuppc qemumips qemumips64 qemumipsel qemumips64el Consider the
+following command form:
+::
+
+   $ runqemu machine rootfs kernel [options]
+
+Supported machines are as follows:
+
+  - qemuarm
+  - qemuarm64
+  - qemux86
+  - qemux86-64
+  - qemuppc
+  - qemumips
+  - qemumips64
+  - qemumipsel
+  - qemumips64el
+
+Consider the
 following example, which uses the ``qemux86-64`` machine, provides a
-root filesystem, provides an image, and uses the ``nographic`` option: $
-runqemu qemux86-64
-tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4
-tmp/deploy/images/qemux86-64/bzImage nographic
+root filesystem, provides an image, and uses the ``nographic`` option: ::
+
+   $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic
 
 Following is a list of variables that can be set in configuration files
 such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``:
@@ -2501,31 +2570,35 @@ such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``:
 
    "QB" means "QEMU Boot".
 
-QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386") QB_OPT_APPEND:
-Options to append to QEMU (e.g. "-show-cursor") QB_DEFAULT_KERNEL:
-Default kernel to boot (e.g. "bzImage") QB_DEFAULT_FSTYPE: Default
-FSTYPE to boot (e.g. "ext4") QB_MEM: Memory (e.g. "-m 512") QB_MACHINE:
-QEMU machine (e.g. "-machine virt") QB_CPU: QEMU cpu (e.g. "-cpu
-qemu32") QB_CPU_KVM: Similar to QB_CPU except used for kvm support (e.g.
-"-cpu kvm64") QB_KERNEL_CMDLINE_APPEND: Options to append to the
-kernel's -append option (e.g. "console=ttyS0 console=tty") QB_DTB: QEMU
-dtb name QB_AUDIO_DRV: QEMU audio driver (e.g. "alsa", set it when
-support audio) QB_AUDIO_OPT: QEMU audio option (e.g. "-soundhw
-ac97,es1370"), which is used when QB_AUDIO_DRV is set. QB_KERNEL_ROOT:
-Kernel's root (e.g. /dev/vda) QB_TAP_OPT: Network option for 'tap' mode
-(e.g. "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device
-virtio-net-device,netdev=net0"). runqemu will replace "@TAP@" with the
-one that is used, such as tap0, tap1 ... QB_SLIRP_OPT: Network option
-for SLIRP mode (e.g. "-netdev user,id=net0 -device
-virtio-net-device,netdev=net0") QB_ROOTFS_OPT: Used as rootfs (e.g.
-"-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device
-virtio-blk-device,drive=disk0"). runqemu will replace "@ROOTFS@" with
-the one which is used, such as core-image-minimal-qemuarm64.ext4.
-QB_SERIAL_OPT: Serial port (e.g. "-serial mon:stdio") QB_TCPSERIAL_OPT:
-tcp serial port option (e.g. " -device virtio-serial-device -chardev
-socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device
-virtconsole,chardev=virtcon" runqemu will replace "@PORT@" with the port
-number which is used.
+::
+
+   QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386")
+   QB_OPT_APPEND: Options to append to QEMU (e.g. "-show-cursor")
+   QB_DEFAULT_KERNEL: Default kernel to boot (e.g. "bzImage")
+   QB_DEFAULT_FSTYPE: Default FSTYPE to boot (e.g. "ext4")
+   QB_MEM: Memory (e.g. "-m 512")
+   QB_MACHINE: QEMU machine (e.g. "-machine virt")
+   QB_CPU: QEMU cpu (e.g. "-cpu qemu32")
+   QB_CPU_KVM: Similar to QB_CPU except used for kvm support (e.g. "-cpu kvm64")
+   QB_KERNEL_CMDLINE_APPEND: Options to append to the kernel's -append
+                             option (e.g. "console=ttyS0 console=tty")
+   QB_DTB: QEMU dtb name
+   QB_AUDIO_DRV: QEMU audio driver (e.g. "alsa", set it when support audio)
+   QB_AUDIO_OPT: QEMU audio option (e.g. "-soundhw ac97,es1370"), which is used
+                 when QB_AUDIO_DRV is set.
+   QB_KERNEL_ROOT: Kernel's root (e.g. /dev/vda)
+   QB_TAP_OPT: Network option for 'tap' mode (e.g.
+               "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device virtio-net-device,netdev=net0").
+                runqemu will replace "@TAP@" with the one that is used, such as tap0, tap1 ...
+   QB_SLIRP_OPT: Network option for SLIRP mode (e.g. "-netdev user,id=net0 -device virtio-net-device,netdev=net0")
+   QB_ROOTFS_OPT: Used as rootfs (e.g.
+                  "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0").
+                  runqemu will replace "@ROOTFS@" with the one which is used, such as
+                  core-image-minimal-qemuarm64.ext4.
+   QB_SERIAL_OPT: Serial port (e.g. "-serial mon:stdio")
+   QB_TCPSERIAL_OPT: tcp serial port option (e.g.
+                     " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device      virtconsole,chardev=virtcon"
+                     runqemu will replace "@PORT@" with the port number which is used.
 
 To use ``runqemu``, set :term:`IMAGE_CLASSES` as
 follows and run ``runqemu``:
@@ -2536,7 +2609,9 @@ follows and run ``runqemu``:
    runqemu help
    .
 
-IMAGE_CLASSES += "qemuboot"
+::
+
+   IMAGE_CLASSES += "qemuboot"
 
 .. _migration-2.2-default-linker-hash-style-changed:
 
@@ -2551,7 +2626,10 @@ recipes. You need to fix these recipes so that they use the expected
 ``LDFLAGS``. Depending on how the software is built, the build system
 used by the software (e.g. a Makefile) might need to be patched.
 However, sometimes making this fix is as simple as adding the following
-to the recipe: TARGET_CC_ARCH += "${LDFLAGS}"
+to the recipe:
+::
+
+   TARGET_CC_ARCH += "${LDFLAGS}"
 
 .. _migration-2.2-kernel-image-base-name-no-longer-uses-kernel-imagetype:
 
@@ -2562,8 +2640,12 @@ The ``KERNEL_IMAGE_BASE_NAME`` variable no longer uses the
 :term:`KERNEL_IMAGETYPE` variable to create the
 image's base name. Because the OpenEmbedded build system can now build
 multiple kernel image types, this part of the kernel image base name as
-been removed leaving only the following: KERNEL_IMAGE_BASE_NAME ?=
-"${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" If you have recipes or
+been removed leaving only the following:
+::
+
+   KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
+
+If you have recipes or
 classes that use ``KERNEL_IMAGE_BASE_NAME`` directly, you might need to
 update the references to ensure they continue to work.
 
@@ -2787,7 +2869,7 @@ Consider the following:
    ``systemd-systemctl-native`` is added to ``PACKAGE_WRITE_DEPS``,
    which is also conditional on "systemd" being in ``DISTRO_FEATURES``.
 
--  *Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``:* You need to
+-  Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``: You need to
    examine any recipe that uses ``SSTATEPOSTINSTFUNCS`` and determine
    steps to take.
 
@@ -2800,8 +2882,7 @@ Consider the following:
    :term:`SYSROOT_PREPROCESS_FUNCS`.
 
    For an example, see the ``pixbufcache`` class in ``meta/classes/`` in
-   the Yocto Project `Source
-   Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__.
+   the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
 
    .. note::
 
@@ -2866,26 +2947,35 @@ Changes to Scripts
 
 The following changes to scripts took place:
 
--  *``oe-find-native-sysroot``:* The usage for the
-   ``oe-find-native-sysroot`` script has changed to the following: $ .
-   oe-find-native-sysroot recipe You must now supply a recipe for recipe
-   as part of the command. Prior to the Yocto Project DISTRO release, it
+-  ``oe-find-native-sysroot``: The usage for the
+   ``oe-find-native-sysroot`` script has changed to the following:
+   ::
+
+      $ . oe-find-native-sysroot recipe
+
+   You must now supply a recipe for recipe
+   as part of the command. Prior to the Yocto Project &DISTRO; release, it
    was not necessary to provide the script with the command.
 
--  *``oe-run-native``:* The usage for the ``oe-run-native`` script has
-   changed to the following: $ oe-run-native native_recipe tool You must
+-  ``oe-run-native``: The usage for the ``oe-run-native`` script has
+   changed to the following:
+   ::
+
+      $ oe-run-native native_recipe tool
+
+   You must
    supply the name of the native recipe and the tool you want to run as
    part of the command. Prior to the Yocto Project DISTRO release, it
    was not necessary to provide the native recipe with the command.
 
--  *``cleanup-workdir``:* The ``cleanup-workdir`` script has been
+-  ``cleanup-workdir``: The ``cleanup-workdir`` script has been
    removed because the script was found to be deleting files it should
    not have, which lead to broken build trees. Rather than trying to
    delete portions of :term:`TMPDIR` and getting it wrong,
    it is recommended that you delete ``TMPDIR`` and have it restored
    from shared state (sstate) on subsequent builds.
 
--  *``wipe-sysroot``:* The ``wipe-sysroot`` script has been removed as
+-  ``wipe-sysroot``: The ``wipe-sysroot`` script has been removed as
    it is no longer needed with recipe-specific sysroots.
 
 .. _migration-2.3-functions:
@@ -2946,8 +3036,8 @@ The following changes took place for BitBake:
    section in the BitBake
    User Manual for additional information.
 
--  *``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2``
-   Removed:* Because the mechanism they were part of is no longer
+-  ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2``
+   Removed: Because the mechanism they were part of is no longer
    necessary with recipe-specific sysroots, the
    ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2``
    variables have been removed.
@@ -3080,29 +3170,29 @@ Removed Recipes
 
 The following recipes have been removed:
 
--  *``linux-yocto 4.8:``* Version 4.8 has been removed. Versions 4.1
+-  ``linux-yocto 4.8``: Version 4.8 has been removed. Versions 4.1
    (LTSI), 4.4 (LTS), 4.9 (LTS/LTSI) and 4.10 are now present.
 
--  *``python-smartpm:``* Functionally replaced by ``dnf``.
+-  ``python-smartpm``: Functionally replaced by ``dnf``.
 
--  *``createrepo:``* Replaced by the ``createrepo-c`` recipe.
+-  ``createrepo``: Replaced by the ``createrepo-c`` recipe.
 
--  *``rpmresolve:``* No longer needed with the move to RPM 4 as RPM
+-  ``rpmresolve``: No longer needed with the move to RPM 4 as RPM
    itself is used instead.
 
--  *``gstreamer:``* Removed the GStreamer Git version recipes as they
+-  ``gstreamer``: Removed the GStreamer Git version recipes as they
    have been stale. ``1.10.``\ x recipes are still present.
 
--  *``alsa-conf-base:``* Merged into ``alsa-conf`` since ``libasound``
+-  ``alsa-conf-base``: Merged into ``alsa-conf`` since ``libasound``
    depended on both. Essentially, no way existed to install only one of
    these.
 
--  *``tremor:``* Moved to ``meta-multimedia``. Fixed-integer Vorbis
+-  ``tremor``: Moved to ``meta-multimedia``. Fixed-integer Vorbis
    decoding is not needed by current hardware. Thus, GStreamer's ivorbis
    plugin has been disabled by default eliminating the need for the
    ``tremor`` recipe in :term:`OpenEmbedded-Core (OE-Core)`.
 
--  *``gummiboot:``* Replaced by ``systemd-boot``.
+-  ``gummiboot``: Replaced by ``systemd-boot``.
 
 .. _migration-2.3-wic-changes:
 
@@ -3135,7 +3225,7 @@ QA Changes
 
 The following QA checks have changed:
 
--  *``unsafe-references-in-binaries``:* The
+-  ``unsafe-references-in-binaries``: The
    ``unsafe-references-in-binaries`` QA check, which was disabled by
    default, has now been removed. This check was intended to detect
    binaries in ``/bin`` that link to libraries in ``/usr/lib`` and have
@@ -3146,7 +3236,7 @@ The following QA checks have changed:
    separate partition from ``/`` is now a rare configuration.
    Consequently, ``unsafe-references-in-binaries`` was removed.
 
--  *``file-rdeps``:* The ``file-rdeps`` QA check is now an error by
+-  ``file-rdeps``: The ``file-rdeps`` QA check is now an error by
    default instead of a warning. Because it is an error instead of a
    warning, you need to address missing runtime dependencies.
 
@@ -3202,8 +3292,15 @@ The following miscellaneous changes have occurred:
 
 -  The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig"
    ``DISTRO_FEATURES`` feature. Distributions that previously set:
-   USE_LDCONFIG = "0" should now instead use the following:
-   DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig"
+   ::
+
+      USE_LDCONFIG = "0"
+
+   should now instead use the following:
+
+   ::
+
+      DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig"
 
 -  The default value of
    :term:`COPYLEFT_LICENSE_INCLUDE` now
@@ -3219,7 +3316,10 @@ The following miscellaneous changes have occurred:
    order to allow module packages from multiple kernel versions to
    co-exist on a target system. If you wish to return to the previous
    naming scheme that does not include the version suffix, use the
-   following: KERNEL_MODULE_PACKAGE_SUFFIX to ""
+   following:
+   ::
+
+      KERNEL_MODULE_PACKAGE_SUFFIX to ""
 
 -  Removal of ``libtool`` ``*.la`` files is now enabled by default. The
    ``*.la`` files are not actually needed on Linux and relocating them
@@ -3285,7 +3385,7 @@ Packaging Changes
 This section provides information about packaging changes that have
 occurred:
 
--  *``python3`` Changes:*
+-  ``python3`` Changes:
 
    -  The main "python3" package now brings in all of the standard
       Python 3 distribution rather than a subset. This behavior matches
@@ -3293,16 +3393,16 @@ occurred:
       wish to install a subset of Python 3, specify ``python-core`` plus
       one or more of the individual packages that are still produced.
 
-   -  *``python3``:* The ``bz2.py``, ``lzma.py``, and
+   -  ``python3``: The ``bz2.py``, ``lzma.py``, and
       ``_compression.py`` scripts have been moved from the
       ``python3-misc`` package to the ``python3-compression`` package.
 
--  *``binutils``:* The ``libbfd`` library is now packaged in a separate
+-  ``binutils``: The ``libbfd`` library is now packaged in a separate
    "libbfd" package. This packaging saves space when certain tools (e.g.
    ``perf``) are installed. In such cases, the tools only need
    ``libbfd`` rather than all the packages in ``binutils``.
 
--  *``util-linux`` Changes:*
+-  ``util-linux`` Changes:
 
    -  The ``su`` program is now packaged in a separate "util-linux-su"
       package, which is only built when "pam" is listed in the
@@ -3326,7 +3426,7 @@ occurred:
       recommended runtime dependency (i.e. ``RRECOMMENDS``) on the
       ``util-linux-ionice`` package.
 
--  *``initscripts``:* The ``sushell`` program is now packaged in a
+-  ``initscripts``: The ``sushell`` program is now packaged in a
    separate "initscripts-sushell" package. This packaging change allows
    systems to pull ``sushell`` in when ``selinux`` is enabled. The
    change also eliminates needing to pull in the entire ``initscripts``
@@ -3334,7 +3434,7 @@ occurred:
    (i.e. ``RDEPENDS``) on the ``sushell`` package when "selinux" is in
    ``DISTRO_FEATURES``.
 
--  *``glib-2.0``:* The ``glib-2.0`` package now has a recommended
+-  ``glib-2.0``: The ``glib-2.0`` package now has a recommended
    runtime dependency (i.e. ``RRECOMMENDS``) on the ``shared-mime-info``
    package, since large portions of GIO are not useful without the MIME
    database. You can remove the dependency by using the
@@ -3351,102 +3451,102 @@ Removed Recipes
 
 The following recipes have been removed:
 
--  *``acpitests``:* This recipe is not maintained.
+-  ``acpitests``: This recipe is not maintained.
 
--  *``autogen-native``:* No longer required by Grub, oe-core, or
+-  ``autogen-native``: No longer required by Grub, oe-core, or
    meta-oe.
 
--  *``bdwgc``:* Nothing in OpenEmbedded-Core requires this recipe. It
+-  ``bdwgc``: Nothing in OpenEmbedded-Core requires this recipe. It
    has moved to meta-oe.
 
--  *``byacc``:* This recipe was only needed by rpm 5.x and has moved to
+-  ``byacc``: This recipe was only needed by rpm 5.x and has moved to
    meta-oe.
 
--  *``gcc (5.4)``:* The 5.4 series dropped the recipe in favor of 6.3 /
+-  ``gcc (5.4)``: The 5.4 series dropped the recipe in favor of 6.3 /
    7.2.
 
--  *``gnome-common``:* Deprecated upstream and no longer needed.
+-  ``gnome-common``: Deprecated upstream and no longer needed.
 
--  *``go-bootstrap-native``:* Go 1.9 does its own bootstrapping so this
+-  ``go-bootstrap-native``: Go 1.9 does its own bootstrapping so this
    recipe has been removed.
 
--  *``guile``:* This recipe was only needed by ``autogen-native`` and
+-  ``guile``: This recipe was only needed by ``autogen-native`` and
    ``remake``. The recipe is no longer needed by either of these
    programs.
 
--  *``libclass-isa-perl``:* This recipe was previously needed for LSB 4,
+-  ``libclass-isa-perl``: This recipe was previously needed for LSB 4,
    no longer needed.
 
--  *``libdumpvalue-perl``:* This recipe was previously needed for LSB 4,
+-  ``libdumpvalue-perl``: This recipe was previously needed for LSB 4,
    no longer needed.
 
--  *``libenv-perl``:* This recipe was previously needed for LSB 4, no
+-  ``libenv-perl``: This recipe was previously needed for LSB 4, no
    longer needed.
 
--  *``libfile-checktree-perl``:* This recipe was previously needed for
+-  ``libfile-checktree-perl``: This recipe was previously needed for
    LSB 4, no longer needed.
 
--  *``libi18n-collate-perl``:* This recipe was previously needed for LSB
+-  ``libi18n-collate-perl``: This recipe was previously needed for LSB
    4, no longer needed.
 
--  *``libiconv``:* This recipe was only needed for ``uclibc``, which was
+-  ``libiconv``: This recipe was only needed for ``uclibc``, which was
    removed in the previous release. ``glibc`` and ``musl`` have their
    own implementations. ``meta-mingw`` still needs ``libiconv``, so it
    has been moved to ``meta-mingw``.
 
--  *``libpng12``:* This recipe was previously needed for LSB. The
+-  ``libpng12``: This recipe was previously needed for LSB. The
    current ``libpng`` is 1.6.x.
 
--  *``libpod-plainer-perl``:* This recipe was previously needed for LSB
+-  ``libpod-plainer-perl``: This recipe was previously needed for LSB
    4, no longer needed.
 
--  *``linux-yocto (4.1)``:* This recipe was removed in favor of 4.4,
+-  ``linux-yocto (4.1)``: This recipe was removed in favor of 4.4,
    4.9, 4.10 and 4.12.
 
--  *``mailx``:* This recipe was previously only needed for LSB
+-  ``mailx``: This recipe was previously only needed for LSB
    compatibility, and upstream is defunct.
 
--  *``mesa (git version only)``:* The git version recipe was stale with
+-  ``mesa (git version only)``: The git version recipe was stale with
    respect to the release version.
 
--  *``ofono (git version only)``:* The git version recipe was stale with
+-  ``ofono (git version only)``: The git version recipe was stale with
    respect to the release version.
 
--  *``portmap``:* This recipe is obsolete and is superseded by
+-  ``portmap``: This recipe is obsolete and is superseded by
    ``rpcbind``.
 
--  *``python3-pygpgme``:* This recipe is old and unmaintained. It was
+-  ``python3-pygpgme``: This recipe is old and unmaintained. It was
    previously required by ``dnf``, which has switched to official
    ``gpgme`` Python bindings.
 
--  *``python-async``:* This recipe has been removed in favor of the
+-  ``python-async``: This recipe has been removed in favor of the
    Python 3 version.
 
--  *``python-gitdb``:* This recipe has been removed in favor of the
+-  ``python-gitdb``: This recipe has been removed in favor of the
    Python 3 version.
 
--  *``python-git``:* This recipe was removed in favor of the Python 3
+-  ``python-git``: This recipe was removed in favor of the Python 3
    version.
 
--  *``python-mako``:* This recipe was removed in favor of the Python 3
+-  ``python-mako``: This recipe was removed in favor of the Python 3
    version.
 
--  *``python-pexpect``:* This recipe was removed in favor of the Python
+-  ``python-pexpect``: This recipe was removed in favor of the Python
    3 version.
 
--  *``python-ptyprocess``:* This recipe was removed in favor of Python
+-  ``python-ptyprocess``: This recipe was removed in favor of Python
    the 3 version.
 
--  *``python-pycurl``:* Nothing is using this recipe in
+-  ``python-pycurl``: Nothing is using this recipe in
    OpenEmbedded-Core (i.e. ``meta-oe``).
 
--  *``python-six``:* This recipe was removed in favor of the Python 3
+-  ``python-six``: This recipe was removed in favor of the Python 3
    version.
 
--  *``python-smmap``:* This recipe was removed in favor of the Python 3
+-  ``python-smmap``: This recipe was removed in favor of the Python 3
    version.
 
--  *``remake``:* Using ``remake`` as the provider of ``virtual/make`` is
+-  ``remake``: Using ``remake`` as the provider of ``virtual/make`` is
    broken. Consequently, this recipe is not needed in OpenEmbedded-Core.
 
 .. _migration-2.4-kernel-device-tree-move:
@@ -3598,17 +3698,17 @@ Packaging Changes
 This section provides information about packaging changes that have
 occurred:
 
--  *``bind-libs``:* The libraries packaged by the bind recipe are in a
+-  ``bind-libs``: The libraries packaged by the bind recipe are in a
    separate ``bind-libs`` package.
 
--  *``libfm-gtk``:* The ``libfm`` GTK+ bindings are split into a
+-  ``libfm-gtk``: The ``libfm`` GTK+ bindings are split into a
    separate ``libfm-gtk`` package.
 
--  *``flex-libfl``:* The flex recipe splits out libfl into a separate
+-  ``flex-libfl``: The flex recipe splits out libfl into a separate
    ``flex-libfl`` package to avoid too many dependencies being pulled in
    where only the library is needed.
 
--  *``grub-efi``:* The ``grub-efi`` configuration is split into a
+-  ``grub-efi``: The ``grub-efi`` configuration is split into a
    separate ``grub-bootconf`` recipe. However, the dependency
    relationship from ``grub-efi`` is through a virtual/grub-bootconf
    provider making it possible to have your own recipe provide the
@@ -3628,42 +3728,42 @@ Removed Recipes
 
 The following recipes have been removed:
 
--  *``gcc``:* The version 6.4 recipes are replaced by 7.x.
+-  ``gcc``: The version 6.4 recipes are replaced by 7.x.
 
--  *``gst-player``:* Renamed to ``gst-examples`` as per upstream.
+-  ``gst-player``: Renamed to ``gst-examples`` as per upstream.
 
--  *``hostap-utils``:* This software package is obsolete.
+-  ``hostap-utils``: This software package is obsolete.
 
--  *``latencytop``:* This recipe is no longer maintained upstream. The
+-  ``latencytop``: This recipe is no longer maintained upstream. The
    last release was in 2009.
 
--  *``libpfm4``:* The only file that requires this recipe is
+-  ``libpfm4``: The only file that requires this recipe is
    ``oprofile``, which has been removed.
 
--  *``linux-yocto``:* The version 4.4, 4.9, and 4.10 recipes have been
+-  ``linux-yocto``: The version 4.4, 4.9, and 4.10 recipes have been
    removed. Versions 4.12, 4.14, and 4.15 remain.
 
--  *``man``:* This recipe has been replaced by modern ``man-db``
+-  ``man``: This recipe has been replaced by modern ``man-db``
 
--  *``mkelfimage``:* This tool has been removed in the upstream coreboot
+-  ``mkelfimage``: This tool has been removed in the upstream coreboot
    project, and is no longer needed with the removal of the ELF image
    type.
 
--  *``nativesdk-postinst-intercept``:* This recipe is not maintained.
+-  ``nativesdk-postinst-intercept``: This recipe is not maintained.
 
--  *``neon``:* This software package is no longer maintained upstream
+-  ``neon``: This software package is no longer maintained upstream
    and is no longer needed by anything in OpenEmbedded-Core.
 
--  *``oprofile``:* The functionality of this recipe is replaced by
+-  ``oprofile``: The functionality of this recipe is replaced by
    ``perf`` and keeping compatibility on an ongoing basis with ``musl``
    is difficult.
 
--  *``pax``:* This software package is obsolete.
+-  ``pax``: This software package is obsolete.
 
--  *``stat``:* This software package is not maintained upstream.
+-  ``stat``: This software package is not maintained upstream.
    ``coreutils`` provides a modern stat binary.
 
--  *``zisofs-tools-native``:* This recipe is no longer needed because
+-  ``zisofs-tools-native``: This recipe is no longer needed because
    the compressed ISO image feature has been removed.
 
 .. _migration-2.5-scripts-and-tools-changes:
@@ -3673,17 +3773,16 @@ Scripts and Tools Changes
 
 The following are changes to scripts and tools:
 
--  *``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer``*: The
+-  ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer``: The
    ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer`` scripts
    previously shipped with poky but not in OpenEmbedded-Core have been
    removed. These scripts are not maintained and are outdated. In many
    cases, they are also limited in scope. The
    ``bitbake-layers create-layer`` command is a direct replacement for
    ``yocto-layer``. See the documentation to create a BSP or kernel
-   recipe in the "`BSP Kernel Recipe
-   Example <&YOCTO_DOCS_BSP_URL;#bsp-kernel-recipe-example>`__" section.
+   recipe in the ":ref:`bsp-guide/bsp:bsp kernel recipe example`" section.
 
--  *``devtool finish``:* ``devtool finish`` now exits with an error if
+-  ``devtool finish``: ``devtool finish`` now exits with an error if
    there are uncommitted changes or a rebase/am in progress in the
    recipe's source repository. If this error occurs, there might be
    uncommitted changes that will not be included in updates to the
@@ -3691,11 +3790,11 @@ The following are changes to scripts and tools:
    situations that the uncommitted changes are inconsequential and you
    want to proceed regardless.
 
--  *``scripts/oe-setup-rpmrepo`` script:* The functionality of
+-  ``scripts/oe-setup-rpmrepo`` script: The functionality of
    ``scripts/oe-setup-rpmrepo`` is replaced by
    ``bitbake package-index``.
 
--  *``scripts/test-dependencies.sh`` script:* The script is largely made
+-  ``scripts/test-dependencies.sh`` script: The script is largely made
    obsolete by the recipe-specific sysroots functionality introduced in
    the previous release.
 
@@ -3725,8 +3824,15 @@ The following are BitBake changes:
    tree" tasks have been removed (e.g. ``fetchall``, ``checkuriall``,
    and the ``*all`` tasks provided by the ``distrodata`` and
    ``archiver`` classes). There is a BitBake option to complete this for
-   any arbitrary task. For example: bitbake <target> -c fetchall should
-   now be replaced with: bitbake <target> --runall=fetch
+   any arbitrary task. For example:
+   ::
+
+      bitbake <target> -c fetchall
+
+   should now be replaced with:
+   ::
+
+      bitbake <target> --runall=fetch
 
 .. _migration-2.5-python-and-python3-changes:
 
@@ -3749,8 +3855,15 @@ one of the packages provided by the Python recipe. You can no longer run
 ``bitbake python-foo`` or have a
 :term:`DEPENDS` on ``python-foo``,
 but doing either of the following causes the package to work as
-expected: IMAGE_INSTALL_append = " python-foo" or RDEPENDS_${PN} =
-"python-foo" The earlier build-time provides behavior was a quirk of the
+expected: ::
+
+   IMAGE_INSTALL_append = " python-foo"
+
+or ::
+
+   RDEPENDS_${PN} = "python-foo"
+
+The earlier build-time provides behavior was a quirk of the
 way the Python manifest file was created. For more information on this
 change please see `this
 commit <http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce>`__.
@@ -3798,17 +3911,36 @@ The following are additional changes:
    ``bitbake/lib/bb``. These are typically used from recipes and
    classes. Any references to the old functions must be updated. The
    following table shows the removed functions and their replacements:
-   *Removed* *Replacement* ============================
-   ============================ base_path_join() oe.path.join()
-   base_path_relative() oe.path.relative() base_path_out()
-   oe.path.format_display() base_read_file() oe.utils.read_file()
-   base_ifelse() oe.utils.ifelse() base_conditional()
-   oe.utils.conditional() base_less_or_equal() oe.utils.less_or_equal()
-   base_version_less_or_equal() oe.utils.version_less_or_equal()
-   base_contains() bb.utils.contains() base_both_contain()
-   oe.utils.both_contain() base_prune_suffix() oe.utils.prune_suffix()
-   oe_filter() oe.utils.str_filter() oe_filter_out()
-   oe.utils.str_filter_out() (or use the \_remove operator).
+
+   +------------------------------+----------------------------------------------------------+
+   | *Removed*                    | *Replacement*                                            |
+   +==============================+==========================================================+
+   | base_path_join()             | oe.path.join()                                           |
+   +------------------------------+----------------------------------------------------------+
+   | base_path_relative()         | oe.path.relative()                                       |
+   +------------------------------+----------------------------------------------------------+
+   | base_path_out()              | oe.path.format_display()                                 |
+   +------------------------------+----------------------------------------------------------+
+   | base_read_file()             | oe.utils.read_file()                                     |
+   +------------------------------+----------------------------------------------------------+
+   | base_ifelse()                | oe.utils.ifelse()                                        |
+   +------------------------------+----------------------------------------------------------+
+   | base_conditional()           | oe.utils.conditional()                                   |
+   +------------------------------+----------------------------------------------------------+
+   | base_less_or_equal()         | oe.utils.less_or_equal()                                 |
+   +------------------------------+----------------------------------------------------------+
+   | base_version_less_or_equal() | oe.utils.version_less_or_equal()                         |
+   +------------------------------+----------------------------------------------------------+
+   | base_contains()              | bb.utils.contains()                                      |
+   +------------------------------+----------------------------------------------------------+
+   | base_both_contain()          | oe.utils.both_contain()                                  |
+   +------------------------------+----------------------------------------------------------+
+   | base_prune_suffix()          | oe.utils.prune_suffix()                                  |
+   +------------------------------+----------------------------------------------------------+
+   | oe_filter()                  | oe.utils.str_filter()                                    |
+   +------------------------------+----------------------------------------------------------+
+   | oe_filter_out()              | oe.utils.str_filter_out() (or use the \_remove operator) |
+   +------------------------------+----------------------------------------------------------+
 
 -  Using ``exit 1`` to explicitly defer a postinstall script until first
    boot is now deprecated since it is not an obvious mechanism and can
@@ -3819,8 +3951,8 @@ The following are additional changes:
    Any failure of a ``pkg_postinst()`` script (including ``exit 1``)
    will trigger a warning during ``do_rootfs``.
 
-   For more information, see the "`Post-Installation
-   Scripts <&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts>`__"
+   For more information, see the
+   ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
    section in the Yocto Project Development Tasks Manual.
 
 -  The ``elf`` image type has been removed. This image type was removed
@@ -3886,46 +4018,55 @@ your configuration.
 Removed Recipes
 ---------------
 
-The following recipes have been removed: *``beecrypt``:* No longer
-needed since moving to RPM 4. *``bigreqsproto``:* Replaced by
-``xorgproto``. *``calibrateproto``:* Removed in favor of ``xinput``.
-*``compositeproto``:* Replaced by ``xorgproto``. *``damageproto``:*
-Replaced by ``xorgproto``. *``dmxproto``:* Replaced by ``xorgproto``.
-*``dri2proto``:* Replaced by ``xorgproto``. *``dri3proto``:* Replaced by
-``xorgproto``. *``eee-acpi-scripts``:* Became obsolete.
-*``fixesproto``:* Replaced by ``xorgproto``. *``fontsproto``:* Replaced
-by ``xorgproto``. *``fstests``:* Became obsolete. *``gccmakedep``:* No
-longer used. *``glproto``:* Replaced by ``xorgproto``.
-*``gnome-desktop3``:* No longer needed. This recipe has moved to
-``meta-oe``. *``icon-naming-utils``:* No longer used since the Sato
-theme was removed in 2016. *``inputproto``:* Replaced by ``xorgproto``.
-*``kbproto``:* Replaced by ``xorgproto``. *``libusb-compat``:* Became
-obsolete. *``libuser``:* Became obsolete. *``libnfsidmap``:* No longer
-an external requirement since ``nfs-utils`` 2.2.1. ``libnfsidmap`` is
-now integrated. *``libxcalibrate``:* No longer needed with ``xinput``
-*``mktemp``:* Became obsolete. The ``mktemp`` command is provided by
-both ``busybox`` and ``coreutils``. *``ossp-uuid``:* Is not being
-maintained and has mostly been replaced by ``uuid.h`` in ``util-linux``.
-*``pax-utils``:* No longer needed. Previous QA tests that did use this
-recipe are now done at build time. *``pcmciautils``:* Became obsolete.
-*``pixz``:* No longer needed. ``xz`` now supports multi-threaded
-compression. *``presentproto``:* Replaced by ``xorgproto``.
-*``randrproto``:* Replaced by ``xorgproto``. *``recordproto``:* Replaced
-by ``xorgproto``. *``renderproto``:* Replaced by ``xorgproto``.
-*``resourceproto``:* Replaced by ``xorgproto``. *``scrnsaverproto``:*
-Replaced by ``xorgproto``. *``trace-cmd``:* Became obsolete. ``perf``
-replaced this recipe's functionally. *``videoproto``:* Replaced by
-``xorgproto``. *``wireless-tools``:* Became obsolete. Superseded by
-``iw``. *``xcmiscproto``:* Replaced by ``xorgproto``. *``xextproto``:*
-Replaced by ``xorgproto``. *``xf86dgaproto``:* Replaced by
-``xorgproto``. *``xf86driproto``:* Replaced by ``xorgproto``.
-*``xf86miscproto``:* Replaced by ``xorgproto``. *``xf86-video-omapfb``:*
-Became obsolete. Use kernel modesetting driver instead.
-*``xf86-video-omap``:* Became obsolete. Use kernel modesetting driver
-instead. *``xf86vidmodeproto``:* Replaced by ``xorgproto``.
-*``xineramaproto``:* Replaced by ``xorgproto``. *``xproto``:* Replaced
-by ``xorgproto``. *``yasm``:* No longer needed since previous usages are
-now satisfied by ``nasm``.
+The following recipes have been removed:
+
+- *beecrypt*: No longer needed since moving to RPM 4.
+- *bigreqsproto*: Replaced by ``xorgproto``.
+- *calibrateproto*: Removed in favor of ``xinput``.
+- *compositeproto*: Replaced by ``xorgproto``.
+- *damageproto*: Replaced by ``xorgproto``.
+- *dmxproto*: Replaced by ``xorgproto``.
+- *dri2proto*: Replaced by ``xorgproto``.
+- *dri3proto*: Replaced by ``xorgproto``.
+- *eee-acpi-scripts*: Became obsolete.
+- *fixesproto*: Replaced by ``xorgproto``.
+- *fontsproto*: Replaced by ``xorgproto``.
+- *fstests*: Became obsolete.
+- *gccmakedep*: No longer used.
+- *glproto*: Replaced by ``xorgproto``.
+- *gnome-desktop3*: No longer needed. This recipe has moved to ``meta-oe``.
+- *icon-naming-utils*: No longer used since the Sato theme was removed in 2016.
+- *inputproto*: Replaced by ``xorgproto``.
+- *kbproto*: Replaced by ``xorgproto``.
+- *libusb-compat*: Became obsolete.
+- *libuser*: Became obsolete.
+- *libnfsidmap*: No longer an external requirement since ``nfs-utils`` 2.2.1. ``libnfsidmap`` is now integrated.
+- *libxcalibrate*: No longer needed with ``xinput``
+- *mktemp*: Became obsolete. The ``mktemp`` command is provided by both ``busybox`` and ``coreutils``.
+- *ossp-uuid*: Is not being maintained and has mostly been replaced by ``uuid.h`` in ``util-linux``.
+- *pax-utils*: No longer needed. Previous QA tests that did use this recipe are now done at build time.
+- *pcmciautils*: Became obsolete.
+- *pixz*: No longer needed. ``xz`` now supports multi-threaded compression.
+- *presentproto*: Replaced by ``xorgproto``.
+- *randrproto*: Replaced by ``xorgproto``.
+- *recordproto*: Replaced by ``xorgproto``.
+- *renderproto*: Replaced by ``xorgproto``.
+- *resourceproto*: Replaced by ``xorgproto``.
+- *scrnsaverproto*: Replaced by ``xorgproto``.
+- *trace-cmd*: Became obsolete. ``perf`` replaced this recipe's functionally.
+- *videoproto*: Replaced by ``xorgproto``.
+- *wireless-tools*: Became obsolete. Superseded by ``iw``.
+- *xcmiscproto*: Replaced by ``xorgproto``.
+- *xextproto*: Replaced by ``xorgproto``.
+- *xf86dgaproto*: Replaced by ``xorgproto``.
+- *xf86driproto*: Replaced by ``xorgproto``.
+- *xf86miscproto*: Replaced by ``xorgproto``.
+- *xf86-video-omapfb*: Became obsolete. Use kernel modesetting driver instead.
+- *xf86-video-omap*: Became obsolete. Use kernel modesetting driver instead.
+- *xf86vidmodeproto*: Replaced by ``xorgproto``.
+- *xineramaproto*: Replaced by ``xorgproto``.
+- *xproto*: Replaced by ``xorgproto``.
+- *yasm*: No longer needed since previous usages are now satisfied by ``nasm``.
 
 .. _migration-2.6-packaging-changes:
 
@@ -3934,30 +4075,30 @@ Packaging Changes
 
 The following packaging changes have been made:
 
--  *``cmake``:* ``cmake.m4`` and ``toolchain`` files have been moved to
+-  *cmake*: ``cmake.m4`` and ``toolchain`` files have been moved to
    the main package.
 
--  *``iptables``:* The ``iptables`` modules have been split into
+-  *iptables*: The ``iptables`` modules have been split into
    separate packages.
 
--  *``alsa-lib``:* ``libasound`` is now in the main ``alsa-lib`` package
+-  *alsa-lib*: ``libasound`` is now in the main ``alsa-lib`` package
    instead of ``libasound``.
 
--  *``glibc``:* ``libnss-db`` is now in its own package along with a
+-  *glibc*: ``libnss-db`` is now in its own package along with a
    ``/var/db/makedbs.sh`` script to update databases.
 
--  *``python`` and ``python3``:* The main package has been removed from
+-  *python and python3*: The main package has been removed from
    the recipe. You must install specific packages or ``python-modules``
    / ``python3-modules`` for everything.
 
--  *``systemtap``:* Moved ``systemtap-exporter`` into its own package.
+-  *systemtap*: Moved ``systemtap-exporter`` into its own package.
 
 .. _migration-2.6-xorg-protocol-dependencies:
 
 XOrg Protocol dependencies
 --------------------------
 
-The "*proto" upstream repositories have been combined into one
+The ``*proto`` upstream repositories have been combined into one
 "xorgproto" repository. Thus, the corresponding recipes have also been
 combined into a single ``xorgproto`` recipe. Any recipes that depend
 upon the older ``*proto`` recipes need to be changed to depend on the
@@ -4024,19 +4165,21 @@ The following changes have been made:
    allows easier and more direct changes.
 
    The ``IMAGE_VERSION_SUFFIX`` variable is set in the ``bitbake.conf``
-   configuration file as follows: IMAGE_VERSION_SUFFIX = "-${DATETIME}"
-
--  Several variables have changed names for consistency: Old Variable
-   Name New Variable Name
-   ========================================================
-   KERNEL_IMAGE_BASE_NAME :term:`KERNEL_IMAGE_NAME`
-   KERNEL_IMAGE_SYMLINK_NAME
-   :term:`KERNEL_IMAGE_LINK_NAME`
-   MODULE_TARBALL_BASE_NAME
-   :term:`MODULE_TARBALL_NAME`
-   MODULE_TARBALL_SYMLINK_NAME
-   :term:`MODULE_TARBALL_LINK_NAME`
-   INITRAMFS_BASE_NAME :term:`INITRAMFS_NAME`
+   configuration file as follows:
+   ::
+
+      IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+
+-  Several variables have changed names for consistency:
+   ::
+
+      Old Variable                  Name New Variable Name
+      ========================================================
+      KERNEL_IMAGE_BASE_NAME        :term:`KERNEL_IMAGE_NAME`
+      KERNEL_IMAGE_SYMLINK_NAME     :term:`KERNEL_IMAGE_LINK_NAME`
+      MODULE_TARBALL_BASE_NAME      :term:`MODULE_TARBALL_NAME`
+      MODULE_TARBALL_SYMLINK_NAME   :term:`MODULE_TARBALL_LINK_NAME`
+      INITRAMFS_BASE_NAME           :term:`INITRAMFS_NAME`
 
 -  The ``MODULE_IMAGE_BASE_NAME`` variable has been removed. The module
    tarball name is now controlled directly with the
@@ -4107,8 +4250,8 @@ Override Changes
 
 The following changes have occurred:
 
--  *The ``virtclass-native`` and ``virtclass-nativesdk`` Overrides Have
-   Been Removed:* The ``virtclass-native`` and ``virtclass-nativesdk``
+-  The ``virtclass-native`` and ``virtclass-nativesdk`` Overrides Have
+   Been Removed: The ``virtclass-native`` and ``virtclass-nativesdk``
    overrides have been deprecated since 2012 in favor of
    ``class-native`` and ``class-nativesdk``, respectively. Both
    ``virtclass-native`` and ``virtclass-nativesdk`` are now dropped.
@@ -4119,8 +4262,8 @@ The following changes have occurred:
       virtclass-multilib-
       overrides for multilib are still valid.
 
--  *The ``forcevariable`` Override Now Has a Higher Priority Than
-   ``libc`` Overrides:* The ``forcevariable`` override is documented to
+-  The ``forcevariable`` Override Now Has a Higher Priority Than
+   ``libc`` Overrides: The ``forcevariable`` override is documented to
    be the highest priority override. However, due to a long-standing
    quirk of how :term:`OVERRIDES` is set, the ``libc``
    overrides (e.g. ``libc-glibc``, ``libc-musl``, and so forth)
@@ -4132,7 +4275,7 @@ The following changes have occurred:
    check how you use ``forcevariable`` and ``libc-*`` overrides in your
    custom layers and configuration files to ensure they make sense.
 
--  *The ``build-${BUILD_OS}`` Override Has Been Removed:* The
+-  The ``build-${BUILD_OS}`` Override Has Been Removed: The
    ``build-${BUILD_OS}``, which is typically ``build-linux``, override
    has been removed because building on a host operating system other
    than a recent version of Linux is neither supported nor recommended.
@@ -4158,10 +4301,16 @@ where machine-specific configurations need to be applied (e.g. for
 ``qemu*`` machines).
 
 Currently, the new recipe packages the following files:
-${sysconfdir}/machine-id ${sysconfdir}/systemd/coredump.conf
-${sysconfdir}/systemd/journald.conf ${sysconfdir}/systemd/logind.conf
-${sysconfdir}/systemd/system.conf ${sysconfdir}/systemd/user.conf If you
-previously used bbappend files to append the ``systemd`` recipe to
+::
+
+   ${sysconfdir}/machine-id
+   ${sysconfdir}/systemd/coredump.conf
+   ${sysconfdir}/systemd/journald.conf
+   ${sysconfdir}/systemd/logind.conf
+   ${sysconfdir}/systemd/system.conf
+   ${sysconfdir}/systemd/user.conf
+
+If you previously used bbappend files to append the ``systemd`` recipe to
 change any of the listed files, you must do so for the ``systemd-conf``
 recipe instead.
 
@@ -4172,13 +4321,13 @@ Automatic Testing Changes
 
 This section provides information about automatic testing changes:
 
--  *``TEST_IMAGE`` Variable Removed:* Prior to this release, you set the
+-  ``TEST_IMAGE`` Variable Removed: Prior to this release, you set the
    ``TEST_IMAGE`` variable to "1" to enable automatic testing for
    successfully built images. The ``TEST_IMAGE`` variable no longer
    exists and has been replaced by the
    :term:`TESTIMAGE_AUTO` variable.
 
--  *Inheriting the ``testimage`` and ``testsdk`` Classes:* Best
+-  Inheriting the ``testimage`` and ``testsdk`` Classes: Best
    practices now dictate that you use the
    :term:`IMAGE_CLASSES` variable rather than the
    :term:`INHERIT` variable when you inherit the
@@ -4231,8 +4380,7 @@ Any failure of a ``pkg_postinst()`` script (including exit 1) triggers
 an error during the :ref:`ref-tasks-rootfs` task.
 
 For more information on post-installation behavior, see the
-"`Post-Installation
-Scripts <&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts>`__"
+":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-2.6-python-3-profile-guided-optimizations:
@@ -4253,8 +4401,12 @@ If you wish to disable Python profile-guided optimization regardless of
 the value of ``MACHINE_FEATURES``, then ensure that
 :term:`PACKAGECONFIG` for the ``python3`` recipe
 does not contain "pgo". You could accomplish the latter using the
-following at the configuration level: PACKAGECONFIG_remove_pn-python3 =
-"pgo" Alternatively, you can set ``PACKAGECONFIG`` using an append file
+following at the configuration level:
+::
+
+   PACKAGECONFIG_remove_pn-python3 = "pgo"
+
+Alternatively, you can set ``PACKAGECONFIG`` using an append file
 for the ``python3`` recipe.
 
 .. _migration-2.6-miscellaneous-changes:
@@ -4267,7 +4419,10 @@ The following miscellaneous changes occurred:
 -  Default to using the Thumb-2 instruction set for armv7a and above. If
    you have any custom recipes that build software that needs to be
    built with the ARM instruction set, change the recipe to set the
-   instruction set as follows: ARM_INSTRUCTION_SET = "arm"
+   instruction set as follows:
+   ::
+
+      ARM_INSTRUCTION_SET = "arm"
 
 -  ``run-postinsts`` no longer uses ``/etc/*-postinsts`` for
    ``dpkg/opkg`` in favor of built-in postinst support. RPM behavior
@@ -4385,10 +4540,11 @@ License Value Corrections
 -------------------------
 
 The following corrections have been made to the
-:term:`LICENSE` values set by recipes: *socat*: Corrected
-``LICENSE`` to be "GPLv2" rather than "GPLv2+". *libgfortran*: Set
-license to "GPL-3.0-with-GCC-exception". *elfutils*: Removed
-"Elfutils-Exception" and set to "GPLv2" for shared libraries
+:term:`LICENSE` values set by recipes:
+
+- *socat*: Corrected ``LICENSE`` to be "GPLv2" rather than "GPLv2+".
+- *libgfortran*: Set license to "GPL-3.0-with-GCC-exception".
+- *elfutils*: Removed "Elfutils-Exception" and set to "GPLv2" for shared libraries
 
 .. _migration-2.7-packaging-changes:
 
@@ -4439,26 +4595,28 @@ This section provides information about packaging changes.
 Removed Recipes
 ---------------
 
-The following recipes have been removed: *gcc*: Drop version 7.3
-recipes. Version 8.3 now remains. *linux-yocto*: Drop versions 4.14 and
-4.18 recipes. Versions 4.19 and 5.0 remain. *go*: Drop version 1.9
-recipes. Versions 1.11 and 1.12 remain. *xvideo-tests*: Became obsolete.
-*libart-lgpl*: Became obsolete. *gtk-icon-utils-native*: These tools are
-now provided by gtk+3-native *gcc-cross-initial*: No longer needed.
-gcc-cross/gcc-crosssdk is now used instead. *gcc-crosssdk-initial*: No
-longer needed. gcc-cross/gcc-crosssdk is now used instead.
-*glibc-initial*: Removed because the benefits of having it for
-site_config are currently outweighed by the cost of building the recipe.
+The following recipes have been removed:
+
+- *gcc*: Drop version 7.3 recipes. Version 8.3 now remains.
+- *linux-yocto*: Drop versions 4.14 and 4.18 recipes. Versions 4.19 and 5.0 remain.
+- *go*: Drop version 1.9 recipes. Versions 1.11 and 1.12 remain.
+- *xvideo-tests*: Became obsolete.
+- *libart-lgpl*: Became obsolete.
+- *gtk-icon-utils-native*: These tools are now provided by gtk+3-native
+- *gcc-cross-initial*: No longer needed. gcc-cross/gcc-crosssdk is now used instead.
+- *gcc-crosssdk-initial*: No longer needed. gcc-cross/gcc-crosssdk is now used instead.
+- *glibc-initial*: Removed because the benefits of having it for site_config are currently outweighed by the cost of building the recipe.
 
 .. _migration-2.7-removed-classes:
 
 Removed Classes
 ---------------
 
-The following classes have been removed: *distutils-tools*: This class
-was never used. *bugzilla.bbclass*: Became obsolete. *distrodata*: This
-functionally has been replaced by a more modern tinfoil-based
-implementation.
+The following classes have been removed:
+
+- *distutils-tools*: This class was never used.
+- *bugzilla.bbclass*: Became obsolete.
+- *distrodata*: This functionally has been replaced by a more modern tinfoil-based implementation.
 
 .. _migration-2.7-miscellaneous-changes:
 
@@ -4471,7 +4629,7 @@ The following miscellaneous changes occurred:
    from the top-level ``scripts`` directory.
 
 -  Perl now builds for the target using
-   ```perl-cross`http://arsv.github.io/perl-cross/ for better
+   `perl-cross <http://arsv.github.io/perl-cross/>`_ for better
    maintainability and improved build performance. This change should
    not present any problems unless you have heavily customized your Perl
    recipe.
@@ -4883,7 +5041,9 @@ need runtime tests enabled for core components, then it is recommended
 that you remove "ptest" from
 :term:`DISTRO_FEATURES` to save a significant
 amount of build time e.g. by adding the following in your configuration:
-DISTRO_FEATURES_remove = "ptest"
+::
+
+   DISTRO_FEATURES_remove = "ptest"
 
 .. _migration-3.1-removed-recipes:
 
@@ -4988,12 +5148,15 @@ parameter instead of the earlier ``name`` which overlapped with the
 generic ``name`` parameter. All recipes using the npm fetcher will need
 to be changed as a result.
 
-An example of the new scheme: SRC_URI =
-"npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \\
-npmsw://${THISDIR}/npm-shrinkwrap.json" Another example where the
-sources are fetched from git rather than an npm repository: SRC_URI =
-"git://github.com/foo/bar.git;protocol=https \\
-npmsw://${THISDIR}/npm-shrinkwrap.json"
+An example of the new scheme: ::
+
+   SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \
+              npmsw://${THISDIR}/npm-shrinkwrap.json"
+
+Another example where the sources are fetched from git rather than an npm repository: ::
+
+   SRC_URI = "git://github.com/foo/bar.git;protocol=https \
+              npmsw://${THISDIR}/npm-shrinkwrap.json"
 
 devtool and recipetool have also been updated to match with the npm
 fetcher changes. Other than producing working and more complete recipes
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst
index ace69e15a7..60ce8efd21 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/ref-classes.rst
@@ -47,7 +47,7 @@ splitting out of debug symbols during packaging).
    even if the recipes do not produce architecture-specific output.
 
    Configuring such recipes for all architectures causes the
-   ```do_package_write_*`` <#ref-tasks-package_write_deb>`__ tasks to
+   ```do_package_write_*`` tasks to
    have different signatures for the machines with different tunings.
    Additionally, unnecessary rebuilds occur every time an image for a
    different ``MACHINE`` is built even when the recipe never changes.
@@ -67,9 +67,8 @@ inherit the ``allarch`` class.
 The ``archiver`` class supports releasing source code and other
 materials with the binaries.
 
-For more details on the source archiver, see the "`Maintaining Open
-Source License Compliance During Your Product's
-Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__"
+For more details on the source archiver, see the
+":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual. You can also see
 the :term:`ARCHIVER_MODE` variable for information
 about the variable flags (varflags) that help control archive creation.
@@ -86,8 +85,8 @@ standardization. This class defines a set of tasks (e.g. ``configure``,
 ``compile`` and so forth) that work for all Autotooled packages. It
 should usually be enough to define a few standard variables and then
 simply ``inherit autotools``. These classes can also work with software
-that emulates Autotools. For more information, see the "`Autotooled
-Package <&YOCTO_DOCS_DEV_URL;#new-recipe-autotooled-package>`__" section
+that emulates Autotools. For more information, see the
+":ref:`new-recipe-autotooled-package`" section
 in the Yocto Project Development Tasks Manual.
 
 By default, the ``autotools*`` classes use out-of-tree builds (i.e.
@@ -177,7 +176,7 @@ example use for this class.
    ::
 
            SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}"
-                  
+
 
    See the "
    Fetchers
@@ -229,8 +228,10 @@ value as a variable flag (varflag) and provide a reason, which is
 reported, if the package is requested to be built as the value. For
 example, if you want to blacklist a recipe called "exoticware", you add
 the following to your ``local.conf`` or distribution configuration:
-INHERIT += "blacklist" PNBLACKLIST[exoticware] = "Not supported by our
-organization."
+::
+
+   INHERIT += "blacklist"
+   PNBLACKLIST[exoticware] = "Not supported by our organization."
 
 .. _ref-classes-buildhistory:
 
@@ -240,8 +241,8 @@ organization."
 The ``buildhistory`` class records a history of build output metadata,
 which can be used to detect possible regressions as well as used for
 analysis of the build output. For more information on using Build
-History, see the "`Maintaining Build Output
-Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__"
+History, see the
+":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-buildstats:
@@ -411,8 +412,7 @@ cross-compilation tools.
 
 The ``cross-canadian`` class provides support for the recipes that build
 the Canadian Cross-compilation tools for SDKs. See the
-"`Cross-Development Toolchain
-Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__"
+":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
 section in the Yocto Project Overview and Concepts Manual for more
 discussion on these cross-compilation tools.
 
@@ -423,8 +423,7 @@ discussion on these cross-compilation tools.
 
 The ``crosssdk`` class provides support for the recipes that build the
 cross-compilation tools used for building SDKs. See the
-"`Cross-Development Toolchain
-Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__"
+":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
 section in the Yocto Project Overview and Concepts Manual for more
 discussion on these cross-compilation tools.
 
@@ -465,8 +464,7 @@ staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``.
 ====================
 
 The ``devshell`` class adds the ``do_devshell`` task. Distribution
-policy dictates whether to include this class. See the "`Using a
-Development Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell>`__"
+policy dictates whether to include this class. See the ":ref:`platdev-appdev-devshell`"
 section in the Yocto Project Development Tasks Manual for more
 information about using ``devshell``.
 
@@ -478,16 +476,26 @@ information about using ``devshell``.
 The ``devupstream`` class uses
 :term:`BBCLASSEXTEND` to add a variant of the
 recipe that fetches from an alternative URI (e.g. Git) instead of a
-tarball. Following is an example: BBCLASSEXTEND = "devupstream:target"
-SRC_URI_class-devupstream = "git://git.example.com/example"
-SRCREV_class-devupstream = "abcd1234" Adding the above statements to
-your recipe creates a variant that has
+tarball. Following is an example:
+::
+
+   BBCLASSEXTEND = "devupstream:target"
+   SRC_URI_class-devupstream = "git://git.example.com/example"
+   SRCREV_class-devupstream = "abcd1234"
+
+Adding the above statements to your recipe creates a variant that has
 :term:`DEFAULT_PREFERENCE` set to "-1".
 Consequently, you need to select the variant of the recipe to use it.
 Any development-specific adjustments can be done by using the
 ``class-devupstream`` override. Here is an example:
-DEPENDS_append_class-devupstream = " gperf-native"
-do_configure_prepend_class-devupstream() { touch ${S}/README } The class
+::
+
+   DEPENDS_append_class-devupstream = " gperf-native"
+   do_configure_prepend_class-devupstream() {
+       touch ${S}/README
+   }
+
+The class
 currently only supports creating a development variant of the target
 recipe, not ``native`` or ``nativesdk`` variants.
 
@@ -587,15 +595,19 @@ that use the :term:`B` variable to point to the directory in
 which the OpenEmbedded build system places the generated objects built
 from the recipes. By default, the ``B`` directory is set to the
 following, which is separate from the source directory (``S``):
-${WORKDIR}/${BPN}/{PV}/ See these variables for more information:
+::
+
+   ${WORKDIR}/${BPN}/{PV}/
+
+See these variables for more information:
 :term:`WORKDIR`, :term:`BPN`, and
 :term:`PV`,
 
 For more information on the ``externalsrc`` class, see the comments in
 ``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`.
 For information on how to use the
-``externalsrc`` class, see the "`Building Software from an External
-Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
+``externalsrc`` class, see the
+":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-extrausers:
@@ -619,15 +631,36 @@ be performed using the
    useradd
    class to add user and group configuration to a specific recipe.
 
-Here is an example that uses this class in an image recipe: inherit
-extrausers EXTRA_USERS_PARAMS = "\\ useradd -p '' tester; \\ groupadd
-developers; \\ userdel nobody; \\ groupdel -g video; \\ groupmod -g 1020
-developers; \\ usermod -s /bin/sh tester; \\ " Here is an example that
-adds two users named "tester-jim" and "tester-sue" and assigns
-passwords: inherit extrausers EXTRA_USERS_PARAMS = "\\ useradd -P
-tester01 tester-jim; \\ useradd -P tester01 tester-sue; \\ " Finally,
-here is an example that sets the root password to "1876*18": inherit
-extrausers EXTRA_USERS_PARAMS = "\\ usermod -P 1876*18 root; \\ "
+Here is an example that uses this class in an image recipe:
+::
+
+   inherit extrausers
+   EXTRA_USERS_PARAMS = "\
+       useradd -p '' tester; \
+       groupadd developers; \
+       userdel nobody; \
+       groupdel -g video; \
+       groupmod -g 1020 developers; \
+       usermod -s /bin/sh tester; \
+       "
+
+Here is an example that adds two users named "tester-jim" and "tester-sue" and assigns
+passwords:
+::
+
+   inherit extrausers
+   EXTRA_USERS_PARAMS = "\
+       useradd -P tester01 tester-jim; \
+       useradd -P tester01 tester-sue; \
+       "
+
+Finally, here is an example that sets the root password to "1876*18":
+::
+
+   inherit extrausers
+   EXTRA_USERS_PARAMS = "\
+       usermod -P 1876*18 root; \
+       "
 
 .. _ref-classes-fontcache:
 
@@ -837,8 +870,7 @@ provided by the recipe ``icecc-create-env-native.bb``.
 .. note::
 
    This script is a modified version and not the one that comes with
-   icecc
-   .
+   icecc.
 
 If you do not want the Icecream distributed compile support to apply to
 specific recipes or classes, you can effectively "blacklist" them by
@@ -863,10 +895,18 @@ At the distribution level, you can inherit the ``icecc`` class to be
 sure that all builders start with the same sstate signatures. After
 inheriting the class, you can then disable the feature by setting the
 :term:`ICECC_DISABLED` variable to "1" as follows:
-INHERIT_DISTRO_append = " icecc" ICECC_DISABLED ??= "1" This practice
+::
+
+   INHERIT_DISTRO_append = " icecc"
+   ICECC_DISABLED ??= "1"
+
+This practice
 makes sure everyone is using the same signatures but also requires
 individuals that do want to use Icecream to enable the feature
-individually as follows in your ``local.conf`` file: ICECC_DISABLED = ""
+individually as follows in your ``local.conf`` file:
+::
+
+   ICECC_DISABLED = ""
 
 .. _ref-classes-image:
 
@@ -884,11 +924,11 @@ then one or more image files are created.
 -  The ``IMAGE_INSTALL`` variable controls the list of packages to
    install into the image.
 
-For information on customizing images, see the "`Customizing
-Images <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage>`__" section
+For information on customizing images, see the
+":ref:`usingpoky-extend-customimage`" section
 in the Yocto Project Development Tasks Manual. For information on how
 images are created, see the
-"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" section in the
+":ref:`images-dev-environment`" section in the
 Yocto Project Overview and Concpets Manual.
 
 .. _ref-classes-image-buildinfo:
@@ -912,19 +952,19 @@ types.
 
 By default, the :ref:`image <ref-classes-image>` class automatically
 enables the ``image_types`` class. The ``image`` class uses the
-``IMGCLASSES`` variable as follows: IMGCLASSES =
-"rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" IMGCLASSES +=
-"${@['populate_sdk_base', 'populate_sdk_ext']['linux' in
-d.getVar("SDK_OS")]}" IMGCLASSES +=
-"${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg',
-'image-live', '', d)}" IMGCLASSES +=
-"${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container',
-'', d)}" IMGCLASSES += "image_types_wic" IMGCLASSES +=
-"rootfs-postcommands" IMGCLASSES += "image-postinst-intercepts" inherit
-${IMGCLASSES}
-
-The ``image_types`` class also handles conversion and compression of
-images.
+``IMGCLASSES`` variable as follows:
+::
+
+   IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}"
+   IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
+   IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}"
+   IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}"
+   IMGCLASSES += "image_types_wic"
+   IMGCLASSES += "rootfs-postcommands"
+   IMGCLASSES += "image-postinst-intercepts"
+   inherit ${IMGCLASSES}
+
+The ``image_types`` class also handles conversion and compression of images.
 
 .. note::
 
@@ -957,7 +997,9 @@ the size of libraries contained in the image.
 
 By default, the class is enabled in the ``local.conf.template`` using
 the :term:`USER_CLASSES` variable as follows:
-USER_CLASSES ?= "buildstats image-mklibs image-prelink"
+::
+
+   USER_CLASSES ?= "buildstats image-mklibs image-prelink"
 
 .. _ref-classes-image-prelink:
 
@@ -971,7 +1013,9 @@ time.
 
 By default, the class is enabled in the ``local.conf.template`` using
 the :term:`USER_CLASSES` variable as follows:
-USER_CLASSES ?= "buildstats image-mklibs image-prelink"
+::
+
+   USER_CLASSES ?= "buildstats image-mklibs image-prelink"
 
 .. _ref-classes-insane:
 
@@ -1000,32 +1044,36 @@ should use :term:`INSANE_SKIP`. For example, to skip
 the check for symbolic link ``.so`` files in the main package of a
 recipe, add the following to the recipe. You need to realize that the
 package name override, in this example ``${PN}``, must be used:
-INSANE_SKIP_${PN} += "dev-so" Please keep in mind that the QA checks
+::
+
+   INSANE_SKIP_${PN} += "dev-so"
+
+Please keep in mind that the QA checks
 exist in order to detect real or potential problems in the packaged
 output. So exercise caution when disabling these checks.
 
 The following list shows the tests you can list with the ``WARN_QA`` and
 ``ERROR_QA`` variables:
 
--  *``already-stripped:``* Checks that produced binaries have not
+-  ``already-stripped:`` Checks that produced binaries have not
    already been stripped prior to the build system extracting debug
    symbols. It is common for upstream software projects to default to
    stripping debug symbols for output binaries. In order for debugging
    to work on the target using ``-dbg`` packages, this stripping must be
    disabled.
 
--  *``arch:``* Checks the Executable and Linkable Format (ELF) type, bit
+-  ``arch:`` Checks the Executable and Linkable Format (ELF) type, bit
    size, and endianness of any binaries to ensure they match the target
    architecture. This test fails if any binaries do not match the type
    since there would be an incompatibility. The test could indicate that
    the wrong compiler or compiler options have been used. Sometimes
    software, like bootloaders, might need to bypass this check.
 
--  *``buildpaths:``* Checks for paths to locations on the build host
+-  ``buildpaths:`` Checks for paths to locations on the build host
    inside the output files. Currently, this test triggers too many false
    positives and thus is not normally enabled.
 
--  *``build-deps:``* Determines if a build-time dependency that is
+-  ``build-deps:`` Determines if a build-time dependency that is
    specified through :term:`DEPENDS`, explicit
    :term:`RDEPENDS`, or task-level dependencies exists
    to match any runtime dependency. This determination is particularly
@@ -1045,20 +1093,20 @@ The following list shows the tests you can list with the ``WARN_QA`` and
    ``initscripts`` recipe is actually built and thus the
    ``initscripts-functions`` package is made available.
 
--  *``compile-host-path:``* Checks the
+-  ``compile-host-path:`` Checks the
    :ref:`ref-tasks-compile` log for indications that
    paths to locations on the build host were used. Using such paths
    might result in host contamination of the build output.
 
--  *``debug-deps:``* Checks that all packages except ``-dbg`` packages
+-  ``debug-deps:`` Checks that all packages except ``-dbg`` packages
    do not depend on ``-dbg`` packages, which would cause a packaging
    bug.
 
--  *``debug-files:``* Checks for ``.debug`` directories in anything but
+-  ``debug-files:`` Checks for ``.debug`` directories in anything but
    the ``-dbg`` package. The debug files should all be in the ``-dbg``
    package. Thus, anything packaged elsewhere is incorrect packaging.
 
--  *``dep-cmp:``* Checks for invalid version comparison statements in
+-  ``dep-cmp:`` Checks for invalid version comparison statements in
    runtime dependency relationships between packages (i.e. in
    :term:`RDEPENDS`,
    :term:`RRECOMMENDS`,
@@ -1069,22 +1117,22 @@ The following list shows the tests you can list with the ``WARN_QA`` and
    comparisons might trigger failures or undesirable behavior when
    passed to the package manager.
 
--  *``desktop:``* Runs the ``desktop-file-validate`` program against any
+-  ``desktop:`` Runs the ``desktop-file-validate`` program against any
    ``.desktop`` files to validate their contents against the
    specification for ``.desktop`` files.
 
--  *``dev-deps:``* Checks that all packages except ``-dev`` or
+-  ``dev-deps:`` Checks that all packages except ``-dev`` or
    ``-staticdev`` packages do not depend on ``-dev`` packages, which
    would be a packaging bug.
 
--  *``dev-so:``* Checks that the ``.so`` symbolic links are in the
+-  ``dev-so:`` Checks that the ``.so`` symbolic links are in the
    ``-dev`` package and not in any of the other packages. In general,
    these symlinks are only useful for development purposes. Thus, the
    ``-dev`` package is the correct location for them. Some very rare
    cases do exist for dynamically loaded modules where these symlinks
    are needed instead in the main package.
 
--  *``file-rdeps:``* Checks that file-level dependencies identified by
+-  ``file-rdeps:`` Checks that file-level dependencies identified by
    the OpenEmbedded build system at packaging time are satisfied. For
    example, a shell script might start with the line ``#!/bin/bash``.
    This line would translate to a file dependency on ``/bin/bash``. Of
@@ -1097,10 +1145,10 @@ The following list shows the tests you can list with the ``WARN_QA`` and
    :term:`RDEPENDS` exist to handle any file-level
    dependency detected in packaged files.
 
--  *``files-invalid:``* Checks for :term:`FILES` variable
+-  ``files-invalid:`` Checks for :term:`FILES` variable
    values that contain "//", which is invalid.
 
--  *``host-user-contaminated:``* Checks that no package produced by the
+-  ``host-user-contaminated:`` Checks that no package produced by the
    recipe contains any files outside of ``/home`` with a user or group
    ID that matches the user running BitBake. A match usually indicates
    that the files are being installed with an incorrect UID/GID, since
@@ -1108,16 +1156,16 @@ The following list shows the tests you can list with the ``WARN_QA`` and
    see the section describing the
    :ref:`ref-tasks-install` task.
 
--  *``incompatible-license:``* Report when packages are excluded from
+-  ``incompatible-license:`` Report when packages are excluded from
    being created due to being marked with a license that is in
    :term:`INCOMPATIBLE_LICENSE`.
 
--  *``install-host-path:``* Checks the
+-  ``install-host-path:`` Checks the
    :ref:`ref-tasks-install` log for indications that
    paths to locations on the build host were used. Using such paths
    might result in host contamination of the build output.
 
--  *``installed-vs-shipped:``* Reports when files have been installed
+-  ``installed-vs-shipped:`` Reports when files have been installed
    within ``do_install`` but have not been included in any package by
    way of the :term:`FILES` variable. Files that do not
    appear in any package cannot be present in an image later on in the
@@ -1125,67 +1173,69 @@ The following list shows the tests you can list with the ``WARN_QA`` and
    installed at all. These files can be deleted at the end of
    ``do_install`` if the files are not needed in any package.
 
--  *``invalid-chars:``* Checks that the recipe metadata variables
+-  ``invalid-chars:`` Checks that the recipe metadata variables
    :term:`DESCRIPTION`,
    :term:`SUMMARY`, :term:`LICENSE`, and
    :term:`SECTION` do not contain non-UTF-8 characters.
    Some package managers do not support such characters.
 
--  *``invalid-packageconfig:``* Checks that no undefined features are
+-  ``invalid-packageconfig:`` Checks that no undefined features are
    being added to :term:`PACKAGECONFIG`. For
    example, any name "foo" for which the following form does not exist:
-   PACKAGECONFIG[foo] = "..."
+   ::
+
+      PACKAGECONFIG[foo] = "..."
 
--  *``la:``* Checks ``.la`` files for any ``TMPDIR`` paths. Any ``.la``
+-  ``la:`` Checks ``.la`` files for any ``TMPDIR`` paths. Any ``.la``
    file containing these paths is incorrect since ``libtool`` adds the
    correct sysroot prefix when using the files automatically itself.
 
--  *``ldflags:``* Ensures that the binaries were linked with the
+-  ``ldflags:`` Ensures that the binaries were linked with the
    :term:`LDFLAGS` options provided by the build system.
    If this test fails, check that the ``LDFLAGS`` variable is being
    passed to the linker command.
 
--  *``libdir:``* Checks for libraries being installed into incorrect
+-  ``libdir:`` Checks for libraries being installed into incorrect
    (possibly hardcoded) installation paths. For example, this test will
    catch recipes that install ``/lib/bar.so`` when ``${base_libdir}`` is
    "lib32". Another example is when recipes install
    ``/usr/lib64/foo.so`` when ``${libdir}`` is "/usr/lib".
 
--  *``libexec:``* Checks if a package contains files in
+-  ``libexec:`` Checks if a package contains files in
    ``/usr/libexec``. This check is not performed if the ``libexecdir``
    variable has been set explicitly to ``/usr/libexec``.
 
--  *``packages-list:``* Checks for the same package being listed
+-  ``packages-list:`` Checks for the same package being listed
    multiple times through the :term:`PACKAGES` variable
    value. Installing the package in this manner can cause errors during
    packaging.
 
--  *``perm-config:``* Reports lines in ``fs-perms.txt`` that have an
+-  ``perm-config:`` Reports lines in ``fs-perms.txt`` that have an
    invalid format.
 
--  *``perm-line:``* Reports lines in ``fs-perms.txt`` that have an
+-  ``perm-line:`` Reports lines in ``fs-perms.txt`` that have an
    invalid format.
 
--  *``perm-link:``* Reports lines in ``fs-perms.txt`` that specify
+-  ``perm-link:`` Reports lines in ``fs-perms.txt`` that specify
    'link' where the specified target already exists.
 
--  *``perms:``* Currently, this check is unused but reserved.
+-  ``perms:`` Currently, this check is unused but reserved.
 
--  *``pkgconfig:``* Checks ``.pc`` files for any
+-  ``pkgconfig:`` Checks ``.pc`` files for any
    :term:`TMPDIR`/:term:`WORKDIR` paths.
    Any ``.pc`` file containing these paths is incorrect since
    ``pkg-config`` itself adds the correct sysroot prefix when the files
    are accessed.
 
--  *``pkgname:``* Checks that all packages in
+-  ``pkgname:`` Checks that all packages in
    :term:`PACKAGES` have names that do not contain
    invalid characters (i.e. characters other than 0-9, a-z, ., +, and
    -).
 
--  *``pkgv-undefined:``* Checks to see if the ``PKGV`` variable is
+-  ``pkgv-undefined:`` Checks to see if the ``PKGV`` variable is
    undefined during :ref:`ref-tasks-package`.
 
--  *``pkgvarcheck:``* Checks through the variables
+-  ``pkgvarcheck:`` Checks through the variables
    :term:`RDEPENDS`,
    :term:`RRECOMMENDS`,
    :term:`RSUGGESTS`,
@@ -1199,7 +1249,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and
    unnecessarily complicate dependencies of other packages within the
    same recipe or have other unintended consequences.
 
--  *``pn-overrides:``* Checks that a recipe does not have a name
+-  ``pn-overrides:`` Checks that a recipe does not have a name
    (:term:`PN`) value that appears in
    :term:`OVERRIDES`. If a recipe is named such that
    its ``PN`` value matches something already in ``OVERRIDES`` (e.g.
@@ -1208,43 +1258,43 @@ The following list shows the tests you can list with the ``WARN_QA`` and
    For example, assignments such as ``FILES_${PN} = "xyz"`` effectively
    turn into ``FILES = "xyz"``.
 
--  *``rpaths:``* Checks for rpaths in the binaries that contain build
+-  ``rpaths:`` Checks for rpaths in the binaries that contain build
    system paths such as ``TMPDIR``. If this test fails, bad ``-rpath``
    options are being passed to the linker commands and your binaries
    have potential security issues.
 
--  *``split-strip:``* Reports that splitting or stripping debug symbols
+-  ``split-strip:`` Reports that splitting or stripping debug symbols
    from binaries has failed.
 
--  *``staticdev:``* Checks for static library files (``*.a``) in
+-  ``staticdev:`` Checks for static library files (``*.a``) in
    non-``staticdev`` packages.
 
--  *``symlink-to-sysroot:``* Checks for symlinks in packages that point
+-  ``symlink-to-sysroot:`` Checks for symlinks in packages that point
    into :term:`TMPDIR` on the host. Such symlinks will
    work on the host, but are clearly invalid when running on the target.
 
--  *``textrel:``* Checks for ELF binaries that contain relocations in
+-  ``textrel:`` Checks for ELF binaries that contain relocations in
    their ``.text`` sections, which can result in a performance impact at
    runtime. See the explanation for the
    ```ELF binary`` <#qa-issue-textrel>`__ message for more information
    regarding runtime performance issues.
 
--  *``unlisted-pkg-lics:``* Checks that all declared licenses applying
+-  ``unlisted-pkg-lics:`` Checks that all declared licenses applying
    for a package are also declared on the recipe level (i.e. any license
    in ``LICENSE_*`` should appear in :term:`LICENSE`).
 
--  *``useless-rpaths:``* Checks for dynamic library load paths (rpaths)
+-  ``useless-rpaths:`` Checks for dynamic library load paths (rpaths)
    in the binaries that by default on a standard system are searched by
    the linker (e.g. ``/lib`` and ``/usr/lib``). While these paths will
    not cause any breakage, they do waste space and are unnecessary.
 
--  *``var-undefined:``* Reports when variables fundamental to packaging
+-  ``var-undefined:`` Reports when variables fundamental to packaging
    (i.e. :term:`WORKDIR`,
    :term:`DEPLOY_DIR`, :term:`D`,
    :term:`PN`, and :term:`PKGD`) are undefined
    during :ref:`ref-tasks-package`.
 
--  *``version-going-backwards:``* If Build History is enabled, reports
+-  ``version-going-backwards:`` If Build History is enabled, reports
    when a package being written out has a lower version than the
    previously written package under the same name. If you are placing
    output packages into a feed and upgrading packages on a target system
@@ -1257,7 +1307,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and
       If you are not using runtime package management on your target
       system, then you do not need to worry about this situation.
 
--  *``xorg-driver-abi:``* Checks that all packages containing Xorg
+-  ``xorg-driver-abi:`` Checks that all packages containing Xorg
    drivers have ABI dependencies. The ``xserver-xorg`` recipe provides
    driver ABI names. All drivers should depend on the ABI versions that
    they have been built against. Driver recipes that include
@@ -1293,9 +1343,8 @@ packages such as ``kernel-vmlinux``.
 
 The ``kernel`` class contains logic that allows you to embed an initial
 RAM filesystem (initramfs) image when you build the kernel image. For
-information on how to build an initramfs, see the "`Building an Initial
-RAM Filesystem (initramfs)
-Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section in
+information on how to build an initramfs, see the
+":ref:`building-an-initramfs-image`" section in
 the Yocto Project Development Tasks Manual.
 
 Various other classes are used by the ``kernel`` and ``module`` classes
@@ -1545,8 +1594,7 @@ and implements the :ref:`ref-tasks-compile` and
 everything needed to build and package a kernel module.
 
 For general information on out-of-tree Linux kernel modules, see the
-"`Incorporating Out-of-Tree
-Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__"
+":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
 section in the Yocto Project Linux Kernel Development Manual.
 
 .. _ref-classes-module-base:
@@ -1569,9 +1617,8 @@ The ``multilib*`` classes provide support for building libraries with
 different target optimizations or target architectures and installing
 them side-by-side in the same image.
 
-For more information on using the Multilib feature, see the "`Combining
-Multiple Versions of Library Files into One
-Image <&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image>`__"
+For more information on using the Multilib feature, see the
+":ref:`combining-multiple-versions-library-files-into-one-image`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-native:
@@ -1597,14 +1644,18 @@ a couple different ways:
       naming convention:
       ::
 
-              myrecipe-native.bb
-                             
+         myrecipe-native.bb
+
 
       Not using this naming convention can lead to subtle problems
       caused by existing code that depends on that naming convention.
 
 -  Create or modify a target recipe that contains the following:
-   :term:`BBCLASSEXTEND` = "native" Inside the
+   ::
+
+      BBCLASSEXTEND = "native"
+
+   Inside the
    recipe, use ``_class-native`` and ``_class-target`` overrides to
    specify any functionality specific to the respective native or target
    case.
@@ -1632,7 +1683,11 @@ couple different ways:
    that the ``nativesdk`` class is inherited last.
 
 -  Create a ``nativesdk`` variant of any recipe by adding the following:
-   :term:`BBCLASSEXTEND` = "nativesdk" Inside the
+   ::
+
+       BBCLASSEXTEND = "nativesdk"
+
+   Inside the
    recipe, use ``_class-nativesdk`` and ``_class-target`` overrides to
    specify any functionality specific to the respective SDK machine or
    target case.
@@ -1643,7 +1698,7 @@ couple different ways:
    ::
 
            nativesdk-myrecipe.bb
-                  
+
 
    Not doing so can lead to subtle problems because code exists that
    depends on the naming convention.
@@ -1675,9 +1730,8 @@ package manager (NPM) <https://en.wikipedia.org/wiki/Npm_(software)>`__.
    npm://
    fetcher to have dependencies fetched and packaged automatically.
 
-For information on how to create NPM packages, see the "`Creating Node
-Package Manager (NPM)
-Packages <&YOCTO_DOCS_DEV_URL;#creating-node-package-manager-npm-packages>`__"
+For information on how to create NPM packages, see the
+":ref:`dev-manual/dev-manual-common-tasks:creating node package manager (npm) packages`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-oelint:
@@ -1706,8 +1760,12 @@ before attempting to fetch it from the upstream specified in
 
 To use this class, inherit it globally and specify
 :term:`SOURCE_MIRROR_URL`. Here is an example:
-INHERIT += "own-mirrors" SOURCE_MIRROR_URL =
-"http://example.com/my-source-mirror" You can specify only a single URL
+::
+
+   INHERIT += "own-mirrors"
+   SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"
+
+You can specify only a single URL
 in ``SOURCE_MIRROR_URL``.
 
 .. _ref-classes-package:
@@ -1742,9 +1800,8 @@ first class listed in this variable is used for image generation.
 If you take the optional step to set up a repository (package feed) on
 the development host that can be used by DNF, you can install packages
 from the feed while you are running the image on the target (i.e.
-runtime installation of packages). For more information, see the "`Using
-Runtime Package
-Management <&YOCTO_DOCS_DEV_URL;#using-runtime-package-management>`__"
+runtime installation of packages). For more information, see the
+":ref:`dev-manual/dev-manual-common-tasks:using runtime package management`"
 section in the Yocto Project Development Tasks Manual.
 
 The package-specific class you choose can affect build-time performance
@@ -1774,9 +1831,9 @@ consider some further things about using RPM:
 You can find additional information on the effects of the package class
 at these two Yocto Project mailing list links:
 
--  `https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html <&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html>`__
+-  https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html
 
--  `https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html <&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006363.html>`__
+-  https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html
 
 .. _ref-classes-package_deb:
 
@@ -1870,9 +1927,8 @@ group recipes (e.g. ``PACKAGES``, ``PACKAGE_ARCH``, ``ALLOW_EMPTY``, and
 so forth). It is highly recommended that all package group recipes
 inherit this class.
 
-For information on how to use this class, see the "`Customizing Images
-Using Custom Package
-Groups <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks>`__"
+For information on how to use this class, see the
+":ref:`usingpoky-extend-customimage-customtasks`"
 section in the Yocto Project Development Tasks Manual.
 
 Previously, this class was called the ``task`` class.
@@ -1937,8 +1993,7 @@ files.
 The ``populate_sdk`` class provides support for SDK-only recipes. For
 information on advantages gained when building a cross-development
 toolchain using the :ref:`ref-tasks-populate_sdk`
-task, see the "`Building an SDK
-Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__"
+task, see the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual.
 
@@ -1950,19 +2005,19 @@ Software Development Kit (eSDK) manual.
 The ``populate_sdk_*`` classes support SDK creation and consist of the
 following classes:
 
--  *``populate_sdk_base``:* The base class supporting SDK creation under
+-  ``populate_sdk_base``: The base class supporting SDK creation under
    all package managers (i.e. DEB, RPM, and opkg).
 
--  *``populate_sdk_deb``:* Supports creation of the SDK given the Debian
+-  ``populate_sdk_deb``: Supports creation of the SDK given the Debian
    package manager.
 
--  *``populate_sdk_rpm``:* Supports creation of the SDK given the RPM
+-  ``populate_sdk_rpm``: Supports creation of the SDK given the RPM
    package manager.
 
--  *``populate_sdk_ipk``:* Supports creation of the SDK given the opkg
+-  ``populate_sdk_ipk``: Supports creation of the SDK given the opkg
    (IPK format) package manager.
 
--  *``populate_sdk_ext``:* Supports extensible SDK creation under all
+-  ``populate_sdk_ext``: Supports extensible SDK creation under all
    package managers.
 
 The ``populate_sdk_base`` class inherits the appropriate
@@ -1977,8 +2032,10 @@ contains the cross-compiler and associated tooling, and the target,
 which contains a target root filesystem that is configured for the SDK
 usage. These two images reside in :term:`SDK_OUTPUT`,
 which consists of the following:
-${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs
-${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs
+::
+
+   ${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs
+   ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs
 
 Finally, the base populate SDK class creates the toolchain environment
 setup script, the tarball of the SDK, and the installer.
@@ -1989,13 +2046,12 @@ These classes are inherited by and used with the ``populate_sdk_base``
 class.
 
 For more information on the cross-development toolchain generation, see
-the "`Cross-Development Toolchain
-Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__"
+the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
 section in the Yocto Project Overview and Concepts Manual. For
 information on advantages gained when building a cross-development
 toolchain using the :ref:`ref-tasks-populate_sdk`
-task, see the "`Building an SDK
-Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__"
+task, see the
+":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual.
 
@@ -2034,8 +2090,8 @@ The ``primport`` class provides functionality for importing
 ``prserv.bbclass``
 ==================
 
-The ``prserv`` class provides functionality for using a `PR
-service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__ in order to
+The ``prserv`` class provides functionality for using a :ref:`PR
+service <dev-manual/dev-manual-common-tasks:working with a pr service>` in order to
 automatically manage the incrementing of the :term:`PR`
 variable for each recipe.
 
@@ -2054,11 +2110,10 @@ runtime tests for recipes that build software that provides these tests.
 
 This class is intended to be inherited by individual recipes. However,
 the class' functionality is largely disabled unless "ptest" appears in
-:term:`DISTRO_FEATURES`. See the "`Testing
-Packages With
-ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in
-the Yocto Project Development Tasks Manual for more information on
-ptest.
+:term:`DISTRO_FEATURES`. See the
+":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+section in the Yocto Project Development Tasks Manual for more information
+on ptest.
 
 .. _ref-classes-ptest-gnome:
 
@@ -2068,10 +2123,9 @@ ptest.
 Enables package tests (ptests) specifically for GNOME packages, which
 have tests intended to be executed with ``gnome-desktop-testing``.
 
-For information on setting up and running ptests, see the "`Testing
-Packages With
-ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in
-the Yocto Project Development Tasks Manual.
+For information on setting up and running ptests, see the
+":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-python-dir:
 
@@ -2142,7 +2196,9 @@ absent from both the sysroot and target packages.
 
 If a recipe needs the ``.la`` files to be installed, then the recipe can
 override the removal by setting ``REMOVE_LIBTOOL_LA`` to "0" as follows:
-REMOVE_LIBTOOL_LA = "0"
+::
+
+   REMOVE_LIBTOOL_LA = "0"
 
 .. note::
 
@@ -2155,9 +2211,9 @@ REMOVE_LIBTOOL_LA = "0"
 ``report-error.bbclass``
 ========================
 
-The ``report-error`` class supports enabling the `error reporting
-tool <&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool>`__, which
-allows you to submit build error information to a central database.
+The ``report-error`` class supports enabling the :ref:`error reporting
+tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`",
+which allows you to submit build error information to a central database.
 
 The class collects debug information for recipe, recipe version, task,
 machine, distro, build system, target system, host distro, branch,
@@ -2182,14 +2238,20 @@ preserves these files for inspection and possible debugging purposes. If
 you would rather have these files deleted to save disk space as the
 build progresses, you can enable ``rm_work`` by adding the following to
 your ``local.conf`` file, which is found in the :term:`Build Directory`.
-INHERIT += "rm_work" If you are
+::
+
+   INHERIT += "rm_work"
+
+If you are
 modifying and building source code out of the work directory for a
 recipe, enabling ``rm_work`` will potentially result in your changes to
 the source being lost. To exclude some recipes from having their work
 directories deleted by ``rm_work``, you can add the names of the recipe
 or recipes you are working on to the ``RM_WORK_EXCLUDE`` variable, which
 can also be set in your ``local.conf`` file. Here is an example:
-RM_WORK_EXCLUDE += "busybox glibc"
+::
+
+   RM_WORK_EXCLUDE += "busybox glibc"
 
 .. _ref-classes-rootfs*:
 
@@ -2219,8 +2281,7 @@ The root filesystem is created from packages using one of the
 :term:`PACKAGE_CLASSES` variable.
 
 For information on how root filesystem images are created, see the
-"`Image
-Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__"
+:ref:`image-generation-dev-environment`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-classes-sanity:
@@ -2339,9 +2400,9 @@ The ``sstate`` class provides support for Shared State (sstate). By
 default, the class is enabled through the
 :term:`INHERIT_DISTRO` variable's default value.
 
-For more information on sstate, see the "`Shared State
-Cache <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__" section in the Yocto
-Project Overview and Concepts Manual.
+For more information on sstate, see the
+":ref:`overview-manual/overview-manual-concepts:shared state cache`"
+section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-classes-staging:
 
@@ -2510,14 +2571,17 @@ You should set :term:`SYSTEMD_SERVICE` to the
 name of the service file. You should also use a package name override to
 indicate the package to which the value applies. If the value applies to
 the recipe's main package, use ``${``\ :term:`PN`\ ``}``. Here
-is an example from the connman recipe: SYSTEMD_SERVICE_${PN} =
-"connman.service" Services are set up to start on boot automatically
+is an example from the connman recipe:
+::
+
+   SYSTEMD_SERVICE_${PN} = "connman.service"
+
+Services are set up to start on boot automatically
 unless you have set
 :term:`SYSTEMD_AUTO_ENABLE` to "disable".
 
-For more information on ``systemd``, see the "`Selecting an
-Initialization
-Manager <&YOCTO_DOCS_DEV_URL;#selecting-an-initialization-manager>`__"
+For more information on ``systemd``, see the
+":ref:`dev-manual/dev-manual-common-tasks:selecting an initialization manager`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-systemd-boot:
@@ -2593,13 +2657,17 @@ The tests are commands that run on the target system over ``ssh``. Each
 test is written in Python and makes use of the ``unittest`` module.
 
 The ``testimage.bbclass`` runs tests on an image when called using the
-following: $ bitbake -c testimage image The ``testimage-auto`` class
+following:
+::
+
+   $ bitbake -c testimage image
+
+The ``testimage-auto`` class
 runs tests on an image after the image is constructed (i.e.
 :term:`TESTIMAGE_AUTO` must be set to "1").
 
 For information on how to enable, run, and create new tests, see the
-"`Performing Automated Runtime
-Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-testsdk:
@@ -2609,7 +2677,10 @@ section in the Yocto Project Development Tasks Manual.
 
 This class supports running automated tests against software development
 kits (SDKs). The ``testsdk`` class runs tests on an SDK when called
-using the following: $ bitbake -c testsdk image
+using the following:
+::
+
+   $ bitbake -c testsdk image
 
 .. note::
 
@@ -2682,7 +2753,9 @@ The ``typecheck`` class provides support for validating the values of
 variables set at the configuration level against their defined types.
 The OpenEmbedded build system allows you to define the type of a
 variable using the "type" varflag. Here is an example:
-IMAGE_FEATURES[type] = "list"
+::
+
+   IMAGE_FEATURES[type] = "list"
 
 .. _ref-classes-uboot-config:
 
@@ -2690,11 +2763,18 @@ IMAGE_FEATURES[type] = "list"
 ========================
 
 The ``uboot-config`` class provides support for U-Boot configuration for
-a machine. Specify the machine in your recipe as follows: UBOOT_CONFIG
-??= <default> UBOOT_CONFIG[foo] = "config,images" You can also specify
-the machine using this method: UBOOT_MACHINE = "config" See the
-:term:`UBOOT_CONFIG` and
-:term:`UBOOT_MACHINE` variables for additional
+a machine. Specify the machine in your recipe as follows:
+::
+
+   UBOOT_CONFIG ??= <default>
+   UBOOT_CONFIG[foo] = "config,images"
+
+You can also specify the machine using this method:
+::
+
+   UBOOT_MACHINE = "config"
+
+See the :term:`UBOOT_CONFIG` and :term:`UBOOT_MACHINE` variables for additional
 information.
 
 .. _ref-classes-uninative:
diff --git a/documentation/ref-manual/ref-devtool-reference.rst b/documentation/ref-manual/ref-devtool-reference.rst
index ca1d7fd0cb..eaca45ae25 100644
--- a/documentation/ref-manual/ref-devtool-reference.rst
+++ b/documentation/ref-manual/ref-devtool-reference.rst
@@ -11,8 +11,7 @@ is a key part of the extensible SDK.
 
 This chapter provides a Quick Reference for the ``devtool`` command. For
 more information on how to apply the command when using the extensible
-SDK, see the "`Using the Extensible
-SDK <&YOCTO_DOCS_SDK_URL;#sdk-extensible>`__" chapter in the Yocto
+SDK, see the ":doc:`../sdk-manual/sdk-extensible`" chapter in the Yocto
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual.
 
@@ -23,66 +22,99 @@ Getting Help
 
 The ``devtool`` command line is organized similarly to Git in that it
 has a number of sub-commands for each function. You can run
-``devtool --help`` to see all the commands: $ devtool -h NOTE: Starting
-bitbake server... usage: devtool [--basepath BASEPATH] [--bbpath BBPATH]
-[-d] [-q] [--color COLOR] [-h] <subcommand> ... OpenEmbedded development
-tool options: --basepath BASEPATH Base directory of SDK / build
-directory --bbpath BBPATH Explicitly specify the BBPATH, rather than
-getting it from the metadata -d, --debug Enable debug output -q, --quiet
-Print only errors --color COLOR Colorize output (where COLOR is auto,
-always, never) -h, --help show this help message and exit subcommands:
-Beginning work on a recipe: add Add a new recipe modify Modify the
-source for an existing recipe upgrade Upgrade an existing recipe Getting
-information: status Show workspace status search Search available
-recipes latest-version Report the latest version of an existing recipe
-check-upgrade-status Report upgradability for multiple (or all) recipes
-Working on a recipe in the workspace: build Build a recipe rename Rename
-a recipe file in the workspace edit-recipe Edit a recipe file
-find-recipe Find a recipe file configure-help Get help on configure
-script options update-recipe Apply changes from external source tree to
-recipe reset Remove a recipe from your workspace finish Finish working
-on a recipe in your workspace Testing changes on target: deploy-target
-Deploy recipe output files to live target machine undeploy-target
-Undeploy recipe output files in live target machine build-image Build
-image including workspace recipe packages Advanced: create-workspace Set
-up workspace in an alternative location export Export workspace into a
-tar archive import Import exported tar archive into workspace extract
-Extract the source for an existing recipe sync Synchronize the source
-tree for an existing recipe Use devtool <subcommand> --help to get help
-on a specific command As directed in the general help output, you can
+``devtool --help`` to see all the commands:
+::
+
+   $ devtool -h
+   NOTE: Starting bitbake server...
+   usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q] [--color COLOR] [-h] <subcommand> ...
+
+   OpenEmbedded development tool
+
+   options:
+     --basepath BASEPATH   Base directory of SDK / build directory
+     --bbpath BBPATH       Explicitly specify the BBPATH, rather than getting it from the metadata
+     -d, --debug           Enable debug output
+     -q, --quiet           Print only errors
+     --color COLOR         Colorize output (where COLOR is auto, always, never)
+     -h, --help            show this help message and exit
+
+   subcommands:
+     Beginning work on a recipe:
+       add                   Add a new recipe
+       modify                Modify the source for an existing recipe
+       upgrade               Upgrade an existing recipe
+     Getting information:
+       status                Show workspace status
+       latest-version        Report the latest version of an existing recipe
+       check-upgrade-status  Report upgradability for multiple (or all) recipes
+       search                Search available recipes
+     Working on a recipe in the workspace:
+       build                 Build a recipe
+       rename                Rename a recipe file in the workspace
+       edit-recipe           Edit a recipe file
+       find-recipe           Find a recipe file
+       configure-help        Get help on configure script options
+       update-recipe         Apply changes from external source tree to recipe
+       reset                 Remove a recipe from your workspace
+       finish                Finish working on a recipe in your workspace
+     Testing changes on target:
+       deploy-target         Deploy recipe output files to live target machine
+       undeploy-target       Undeploy recipe output files in live target machine
+       build-image           Build image including workspace recipe packages
+     Advanced:
+       create-workspace      Set up workspace in an alternative location
+       extract               Extract the source for an existing recipe
+       sync                  Synchronize the source tree for an existing recipe
+       menuconfig            Alter build-time configuration for a recipe
+       import                Import exported tar archive into workspace
+       export                Export workspace into a tar archive
+     other:
+       selftest-reverse      Reverse value (for selftest)
+       pluginfile            Print the filename of this plugin
+       bbdir                 Print the BBPATH directory of this plugin
+       count                 How many times have this plugin been registered.
+       multiloaded           How many times have this plugin been initialized
+   Use devtool <subcommand> --help to get help on a specific command
+
+As directed in the general help output, you can
 get more syntax on a specific command by providing the command name and
-using "--help": $ devtool add --help NOTE: Starting bitbake server...
-usage: devtool add [-h] [--same-dir \| --no-same-dir] [--fetch URI]
-[--fetch-dev] [--version VERSION] [--no-git] [--srcrev SRCREV \|
---autorev] [--srcbranch SRCBRANCH] [--binary] [--also-native]
-[--src-subdir SUBDIR] [--mirrors] [--provides PROVIDES] [recipename]
-[srctree] [fetchuri] Adds a new recipe to the workspace to build a
-specified source tree. Can optionally fetch a remote URI and unpack it
-to create the source tree. arguments: recipename Name for new recipe to
-add (just name - no version, path or extension). If not specified, will
-attempt to auto-detect it. srctree Path to external source tree. If not
-specified, a subdirectory of /home/scottrif/poky/build/workspace/sources
-will be used. fetchuri Fetch the specified URI and extract it to create
-the source tree options: -h, --help show this help message and exit
---same-dir, -s Build in same directory as source --no-same-dir Force
-build in a separate build directory --fetch URI, -f URI Fetch the
-specified URI and extract it to create the source tree (deprecated -
-pass as positional argument instead) --fetch-dev For npm, also fetch
-devDependencies --version VERSION, -V VERSION Version to use within
-recipe (PV) --no-git, -g If fetching source, do not set up source tree
-as a git repository --srcrev SRCREV, -S SRCREV Source revision to fetch
-if fetching from an SCM such as git (default latest) --autorev, -a When
-fetching from a git repository, set SRCREV in the recipe to a floating
-revision instead of fixed --srcbranch SRCBRANCH, -B SRCBRANCH Branch in
-source repository if fetching from an SCM such as git (default master)
---binary, -b Treat the source tree as something that should be installed
-verbatim (no compilation, same directory structure). Useful with binary
-packages e.g. RPMs. --also-native Also add native variant (i.e. support
-building recipe for the build host as well as the target machine)
---src-subdir SUBDIR Specify subdirectory within source tree to use
---mirrors Enable PREMIRRORS and MIRRORS for source tree fetching
-(disable by default). --provides PROVIDES, -p PROVIDES Specify an alias
-for the item provided by the recipe. E.g. virtual/libgl
+using "--help":
+::
+
+   $ devtool add --help
+   NOTE: Starting bitbake server...
+   usage: devtool add [-h] [--same-dir | --no-same-dir] [--fetch URI] [--npm-dev] [--version VERSION] [--no-git] [--srcrev SRCREV | --autorev] [--srcbranch SRCBRANCH] [--binary] [--also-native] [--src-subdir SUBDIR] [--mirrors]
+                      [--provides PROVIDES]
+                      [recipename] [srctree] [fetchuri]
+
+   Adds a new recipe to the workspace to build a specified source tree. Can optionally fetch a remote URI and unpack it to create the source tree.
+
+   arguments:
+     recipename            Name for new recipe to add (just name - no version, path or extension). If not specified, will attempt to auto-detect it.
+     srctree               Path to external source tree. If not specified, a subdirectory of /media/build1/poky/build/workspace/sources will be used.
+     fetchuri              Fetch the specified URI and extract it to create the source tree
+
+   options:
+     -h, --help            show this help message and exit
+     --same-dir, -s        Build in same directory as source
+     --no-same-dir         Force build in a separate build directory
+     --fetch URI, -f URI   Fetch the specified URI and extract it to create the source tree (deprecated - pass as positional argument instead)
+     --npm-dev             For npm, also fetch devDependencies
+     --version VERSION, -V VERSION
+                           Version to use within recipe (PV)
+     --no-git, -g          If fetching source, do not set up source tree as a git repository
+     --srcrev SRCREV, -S SRCREV
+                           Source revision to fetch if fetching from an SCM such as git (default latest)
+     --autorev, -a         When fetching from a git repository, set SRCREV in the recipe to a floating revision instead of fixed
+     --srcbranch SRCBRANCH, -B SRCBRANCH
+                           Branch in source repository if fetching from an SCM such as git (default master)
+     --binary, -b          Treat the source tree as something that should be installed verbatim (no compilation, same directory structure). Useful with binary packages e.g. RPMs.
+     --also-native         Also add native variant (i.e. support building recipe for the build host as well as the target machine)
+     --src-subdir SUBDIR   Specify subdirectory within source tree to use
+     --mirrors             Enable PREMIRRORS and MIRRORS for source tree fetching (disable by default).
+     --provides PROVIDES, -p PROVIDES
+                           Specify an alias for the item provided by the recipe. E.g. virtual/libgl
 
 .. _devtool-the-workspace-layer-structure:
 
@@ -99,22 +131,35 @@ The following figure shows the workspace structure:
    :align: center
    :scale: 70%
 
-attic - A directory created if devtool believes it must preserve
-anything when you run "devtool reset". For example, if you run "devtool
-add", make changes to the recipe, and then run "devtool reset", devtool
-takes notice that the file has been changed and moves it into the attic
-should you still want the recipe. README - Provides information on what
-is in workspace layer and how to manage it. .devtool_md5 - A checksum
-file used by devtool. appends - A directory that contains \*.bbappend
-files, which point to external source. conf - A configuration directory
-that contains the layer.conf file. recipes - A directory containing
-recipes. This directory contains a folder for each directory added whose
-name matches that of the added recipe. devtool places the recipe.bb file
-within that sub-directory. sources - A directory containing a working
-copy of the source files used when building the recipe. This is the
-default directory used as the location of the source tree when you do
-not provide a source tree path. This directory contains a folder for
-each set of source files matched to a corresponding recipe.
+::
+
+   attic - A directory created if devtool believes it must preserve
+           anything when you run "devtool reset".  For example, if you
+           run "devtool add", make changes to the recipe, and then
+           run "devtool reset", devtool takes notice that the file has
+           been changed and moves it into the attic should you still
+           want the recipe.
+
+   README - Provides information on what is in workspace layer and how to
+            manage it.
+
+   .devtool_md5 - A checksum file used by devtool.
+
+   appends - A directory that contains *.bbappend files, which point to
+             external source.
+
+   conf - A configuration directory that contains the layer.conf file.
+
+   recipes - A directory containing recipes.  This directory contains a
+             folder for each directory added whose name matches that of the
+             added recipe.  devtool places the recipe.bb file
+             within that sub-directory.
+
+   sources - A directory containing a working copy of the source files used
+             when building the recipe.  This is the default directory used
+             as the location of the source tree when you do not provide a
+             source tree path.  This directory contains a folder for each
+             set of source files matched to a corresponding recipe.
 
 .. _devtool-adding-a-new-recipe-to-the-workspace:
 
@@ -127,8 +172,10 @@ you. The source files the recipe uses should exist in an external area.
 
 The following example creates and adds a new recipe named ``jackson`` to
 a workspace layer the tool creates. The source code built by the recipes
-resides in ``/home/user/sources/jackson``: $ devtool add jackson
-/home/user/sources/jackson
+resides in ``/home/user/sources/jackson``:
+::
+
+   $ devtool add jackson /home/user/sources/jackson
 
 If you add a recipe and the workspace layer does not exist, the command
 creates the layer and populates it as described in "`The Workspace Layer
@@ -145,35 +192,38 @@ external source tree.
    that these packages exist on the target hardware before attempting to
    run your application. If dependent packages (e.g. libraries) do not
    exist on the target, your application, when run, will fail to find
-   those functions. For more information, see the "
-   Deploying Your Software on the Target Machine
-   " section.
+   those functions. For more information, see the
+   ":ref:`ref-manual/ref-devtool-reference:deploying your software on the target machine`"
+   section.
 
 By default, ``devtool add`` uses the latest revision (i.e. master) when
 unpacking files from a remote URI. In some cases, you might want to
 specify a source revision by branch, tag, or commit hash. You can
 specify these options when using the ``devtool add`` command:
 
--  To specify a source branch, use the ``--srcbranch`` option: $ devtool
-   add --srcbranch DISTRO_NAME_NO_CAP jackson /home/user/sources/jackson
+-  To specify a source branch, use the ``--srcbranch`` option:
+   ::
+
+      $ devtool add --srcbranch DISTRO_NAME_NO_CAP jackson /home/user/sources/jackson
+
    In the previous example, you are checking out the DISTRO_NAME_NO_CAP
    branch.
 
 -  To specify a specific tag or commit hash, use the ``--srcrev``
-   option: $ devtool add --srcrev DISTRO_REL_TAG jackson
-   /home/user/sources/jackson $ devtool add --srcrev some_commit_hash
-   /home/user/sources/jackson The previous examples check out the
+   option:
+   ::
+
+      $ devtool add --srcrev DISTRO_REL_TAG jackson /home/user/sources/jackson
+      $ devtool add --srcrev some_commit_hash /home/user/sources/jackson
+
+   The previous examples check out the
    DISTRO_REL_TAG tag and the commit associated with the
    some_commit_hash hash.
 
 .. note::
 
    If you prefer to use the latest revision every time the recipe is
-   built, use the options
-   --autorev
-   or
-   -a
-   .
+   built, use the options --autorev or -a.
 
 .. _devtool-extracting-the-source-for-an-existing-recipe:
 
@@ -219,8 +269,12 @@ The ``devtool modify`` command extracts the source for a recipe, sets it
 up as a Git repository if the source had not already been fetched from
 Git, checks out a branch for development, and applies any patches from
 the recipe as commits on top. You can use the following command to
-checkout the source files: $ devtool modify recipe Using the above
-command form, ``devtool`` uses the existing recipe's
+checkout the source files:
+::
+
+   $ devtool modify recipe
+
+Using the above command form, ``devtool`` uses the existing recipe's
 :term:`SRC_URI` statement to locate the upstream source,
 extracts the source into the default sources location in the workspace.
 The default development branch used is "devtool".
@@ -255,16 +309,24 @@ compile, and test the code.
 
 When you are satisfied with the results and you have committed your
 changes to the Git repository, you can then run the
-``devtool update-recipe`` to create the patches and update the recipe: $
-devtool update-recipe recipe If you run the ``devtool update-recipe``
+``devtool update-recipe`` to create the patches and update the recipe:
+::
+
+   $ devtool update-recipe recipe
+
+If you run the ``devtool update-recipe``
 without committing your changes, the command ignores the changes.
 
 Often, you might want to apply customizations made to your software in
 your own layer rather than apply them to the original recipe. If so, you
 can use the ``-a`` or ``--append`` option with the
 ``devtool update-recipe`` command. These options allow you to specify
-the layer into which to write an append file: $ devtool update-recipe
-recipe -a base-layer-directory The ``*.bbappend`` file is created at the
+the layer into which to write an append file:
+::
+
+   $ devtool update-recipe recipe -a base-layer-directory
+
+The ``*.bbappend`` file is created at the
 appropriate path within the specified layer directory, which may or may
 not be in your ``bblayers.conf`` file. If an append file already exists,
 the command updates it appropriately.
@@ -287,7 +349,7 @@ particular recipe.
 .. note::
 
    -  For the ``oe-core`` layer, recipe maintainers come from the
-      ```maintainers.inc`http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
+      `maintainers.inc <http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc>`_
       file.
 
    -  If the recipe is using the :ref:`bitbake:git-fetcher`
@@ -296,14 +358,21 @@ particular recipe.
       recipe's latest version tag.
 
 As with all ``devtool`` commands, you can get help on the individual
-command: $ devtool check-upgrade-status -h NOTE: Starting bitbake
-server... usage: devtool check-upgrade-status [-h] [--all] [recipe
-[recipe ...]] Prints a table of recipes together with versions currently
-provided by recipes, and latest upstream versions, when there is a later
-version available arguments: recipe Name of the recipe to report (omit
-to report upgrade info for all recipes) options: -h, --help show this
-help message and exit --all, -a Show all recipes, not just recipes
-needing upgrade
+command:
+::
+
+   $ devtool check-upgrade-status -h
+   NOTE: Starting bitbake server...
+   usage: devtool check-upgrade-status [-h] [--all] [recipe [recipe ...]]
+
+   Prints a table of recipes together with versions currently provided by recipes, and latest upstream versions, when there is a later version available
+
+   arguments:
+     recipe      Name of the recipe to report (omit to report upgrade info for all recipes)
+
+   options:
+     -h, --help  show this help message and exit
+     --all, -a   Show all recipes, not just recipes needing upgrade
 
 Unless you provide a specific recipe name on the command line, the
 command checks all recipes in all configured layers.
@@ -317,21 +386,18 @@ satisfied.
 .. note::
 
    When a reason for not upgrading displays, the reason is usually
-   written into the recipe using the
-   RECIPE_NO_UPDATE_REASON
-   variable. See the
-   base-passwd.bb
-   recipe for an example.
-
-$ devtool check-upgrade-status ... NOTE: acpid 2.0.30 2.0.31 Ross Burton
-<ross.burton@intel.com> NOTE: u-boot-fw-utils 2018.11 2019.01 Marek
-Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff
-NOTE: u-boot-tools 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com>
-d3689267f92c5956e09cc7d1baa4700141662bff . . . NOTE: base-passwd 3.5.29
-3.5.45 Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to:
-Version 3.5.38 requires cdebconf for update-passwd utility NOTE: busybox
-1.29.2 1.30.0 Andrej Valek <andrej.valek@siemens.com> NOTE: dbus-test
-1.12.10 1.12.12 Chen Qi <Qi.Chen@windriver.com>
+   written into the recipe using the RECIPE_NO_UPDATE_REASON
+   variable. See the base-passwd.bb recipe for an example.
+
+::
+
+   $ devtool check-upgrade-status ...
+   NOTE: acpid 2.0.30 2.0.31 Ross Burton <ross.burton@intel.com>
+   NOTE: u-boot-fw-utils 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff
+   NOTE: u-boot-tools 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff . . .
+   NOTE: base-passwd 3.5.29 3.5.45 Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to: Version 3.5.38 requires cdebconf for update-passwd utility
+   NOTE: busybox 1.29.2 1.30.0 Andrej Valek <andrej.valek@siemens.com>
+   NOTE: dbus-test 1.12.10 1.12.12 Chen Qi <Qi.Chen@windriver.com>
 
 .. _devtool-upgrading-a-recipe:
 
@@ -341,17 +407,13 @@ Upgrading a Recipe
 As software matures, upstream recipes are upgraded to newer versions. As
 a developer, you need to keep your local recipes up-to-date with the
 upstream version releases. Several methods exist by which you can
-upgrade recipes. You can read about them in the "`Upgrading
-Recipes <&YOCTO_DOCS_DEV_URL;#gs-upgrading-recipes>`__" section of the
-Yocto Project Development Tasks Manual. This section overviews the
-``devtool upgrade`` command.
+upgrade recipes. You can read about them in the ":ref:`gs-upgrading-recipes`"
+section of the Yocto Project Development Tasks Manual. This section
+overviews the ``devtool upgrade`` command.
 
-.. note::
-
-   Before you upgrade a recipe, you can check on its upgrade status. See
-   the "
-   Checking on the Upgrade Status of a Recipe
-   " for more information.
+Before you upgrade a recipe, you can check on its upgrade status. See
+the ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`" section
+for more information.
 
 The ``devtool upgrade`` command upgrades an existing recipe to a more
 recent version of the recipe upstream. The command puts the upgraded
@@ -369,14 +431,11 @@ revision to which you want to upgrade (i.e. the
 :term:`SRCREV`), whether or not to apply patches, and so
 forth.
 
-You can read more on the ``devtool upgrade`` workflow in the "`Use
-``devtool upgrade`` to Create a Version of the Recipe that Supports a
-Newer Version of the
-Software <&YOCTO_DOCS_SDK_URL;#sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software>`__"
+You can read more on the ``devtool upgrade`` workflow in the
+":ref:`sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual. You can also see an example of
-how to use ``devtool upgrade`` in the "`Using
-``devtool upgrade`` <&YOCTO_DOCS_DEV_URL;#gs-using-devtool-upgrade>`__"
+how to use ``devtool upgrade`` in the ":ref:`gs-using-devtool-upgrade`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _devtool-resetting-a-recipe:
@@ -397,10 +456,13 @@ files have been modified, the command preserves the modified files in a
 separate "attic" subdirectory under the workspace layer.
 
 Here is an example that resets the workspace directory that contains the
-``mtr`` recipe: $ devtool reset mtr NOTE: Cleaning sysroot for recipe
-mtr... NOTE: Leaving source tree
-/home/scottrif/poky/build/workspace/sources/mtr as-is; if you no longer
-need it then please delete it manually $
+``mtr`` recipe:
+::
+
+   $ devtool reset mtr
+   NOTE: Cleaning sysroot for recipe mtr...
+   NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually
+   $
 
 .. _devtool-building-your-recipe:
 
@@ -414,8 +476,10 @@ Use the ``devtool build`` command to build your recipe. The
 When you use the ``devtool build`` command, you must supply the root
 name of the recipe (i.e. do not provide versions, paths, or extensions).
 You can use either the "-s" or the "--disable-parallel-make" options to
-disable parallel makes during the build. Here is an example: $ devtool
-build recipe
+disable parallel makes during the build. Here is an example:
+::
+
+   $ devtool build recipe
 
 .. _devtool-building-your-image:
 
@@ -429,8 +493,10 @@ device for testing. For proper integration into a final image, you need
 to edit your custom image recipe appropriately.
 
 When you use the ``devtool build-image`` command, you must supply the
-name of the image. This command has no command line options: $ devtool
-build-image image
+name of the image. This command has no command line options:
+::
+
+   $ devtool build-image image
 
 .. _devtool-deploying-your-software-on-the-target-machine:
 
@@ -438,7 +504,11 @@ Deploying Your Software on the Target Machine
 =============================================
 
 Use the ``devtool deploy-target`` command to deploy the recipe's build
-output to the live target machine: $ devtool deploy-target recipe target
+output to the live target machine:
+::
+
+   $ devtool deploy-target recipe target
+
 The target is the address of the target machine, which must be running
 an SSH server (i.e. ``user@hostname[:destdir]``).
 
@@ -485,8 +555,13 @@ Removing Your Software from the Target Machine
 Use the ``devtool undeploy-target`` command to remove deployed build
 output from the target machine. For the ``devtool undeploy-target``
 command to work, you must have previously used the
-```devtool deploy-target`` <#devtool-deploying-your-software-on-the-target-machine>`__
-command. $ devtool undeploy-target recipe target The target is the
+":ref:`devtool deploy-target <ref-manual/ref-devtool-reference:deploying your software on the target machine>`"
+command.
+::
+
+   $ devtool undeploy-target recipe target
+
+The target is the
 address of the target machine, which must be running an SSH server (i.e.
 ``user@hostname``).
 
@@ -501,12 +576,17 @@ new workspace layer, it is populated with the ``README`` file and the
 ``conf`` directory only.
 
 The following example creates a new workspace layer in your current
-working and by default names the workspace layer "workspace": $ devtool
-create-workspace
+working and by default names the workspace layer "workspace":
+::
+
+   $ devtool create-workspace
 
 You can create a workspace layer anywhere by supplying a pathname with
 the command. The following command creates a new workspace layer named
-"new-workspace": $ devtool create-workspace /home/scottrif/new-workspace
+"new-workspace":
+::
+
+   $ devtool create-workspace /home/scottrif/new-workspace
 
 .. _devtool-get-the-status-of-the-recipes-in-your-workspace:
 
@@ -517,13 +597,19 @@ Use the ``devtool status`` command to list the recipes currently in your
 workspace. Information includes the paths to their respective external
 source trees.
 
-The ``devtool status`` command has no command-line options: $ devtool
-status Following is sample output after using
-```devtool add`` <#devtool-adding-a-new-recipe-to-the-workspace>`__ to
-create and add the ``mtr_0.86.bb`` recipe to the ``workspace``
-directory: $ devtool status mtr:
-/home/scottrif/poky/build/workspace/sources/mtr
-(/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb) $
+The ``devtool status`` command has no command-line options:
+::
+
+   $ devtool status
+
+Following is sample output after using
+:ref:`devtool add <ref-manual/ref-devtool-reference:adding a new recipe to the workspace layer>`
+to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:
+::
+
+   $ devtool status mtr
+   :/home/scottrif/poky/build/workspace/sources/mtr (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb)
+   $
 
 .. _devtool-search-for-available-target-recipes:
 
diff --git a/documentation/ref-manual/ref-features.rst b/documentation/ref-manual/ref-features.rst
index 0e901edaeb..ae5a0e3b24 100644
--- a/documentation/ref-manual/ref-features.rst
+++ b/documentation/ref-manual/ref-features.rst
@@ -26,8 +26,11 @@ One method you can use to determine which recipes are checking to see if
 a particular feature is contained or not is to ``grep`` through the
 :term:`Metadata` for the feature. Here is an example that
 discovers the recipes whose build is potentially changed based on a
-given feature: $ cd poky $ git grep
-'contains.*MACHINE_FEATURES.*feature'
+given feature:
+::
+
+   $ cd poky
+   $ git grep 'contains.*MACHINE_FEATURES.*feature'
 
 .. _ref-features-machine:
 
@@ -115,8 +118,7 @@ metadata:
 -  *api-documentation:* Enables generation of API documentation during
    recipe builds. The resulting documentation is added to SDK tarballs
    when the ``bitbake -c populate_sdk`` command is used. See the
-   "`Adding API Documentation to the Standard
-   SDK <&YOCTO_DOCS_SDK_URL;#adding-api-documentation-to-the-standard-sdk>`__"
+   ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding api documentation to the standard sdk`"
    section in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual.
 
@@ -154,8 +156,7 @@ metadata:
 
 -  *ptest:* Enables building the package tests where supported by
    individual recipes. For more information on package tests, see the
-   "`Testing Packages With
-   ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section
+   ":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" section
    in the Yocto Project Development Tasks Manual.
 
 -  *smbfs:* Include SMB networks client support (for mounting
@@ -237,8 +238,8 @@ The following image features are available for all images:
 -  *ptest-pkgs:* Installs ptest packages for all ptest-enabled recipes.
 
 -  *read-only-rootfs:* Creates an image whose root filesystem is
-   read-only. See the "`Creating a Read-Only Root
-   Filesystem <&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem>`__"
+   read-only. See the
+   ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
    section in the Yocto Project Development Tasks Manual for more
    information.
 
@@ -263,8 +264,7 @@ these valid features is as follows:
 
 -  *perf:* Installs profiling tools such as ``perf``, ``systemtap``, and
    ``LTTng``. For general information on user-space tools, see the
-   `Yocto Project Application Development and the Extensible Software
-   Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual.
+   :doc:`../sdk-manual/sdk-manual` manual.
 
 -  *ssh-server-dropbear:* Installs the Dropbear minimal SSH server.
 
@@ -275,12 +275,10 @@ these valid features is as follows:
    will not be installed.
 
 -  *tools-debug:* Installs debugging tools such as ``strace`` and
-   ``gdb``. For information on GDB, see the "`Debugging With the GNU
-   Project Debugger (GDB)
-   Remotely <&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug>`__" section
+   ``gdb``. For information on GDB, see the
+   ":ref:`platdev-gdb-remotedebug`" section
    in the Yocto Project Development Tasks Manual. For information on
-   tracing and profiling, see the `Yocto Project Profiling and Tracing
-   Manual <&YOCTO_DOCS_PROF_URL;>`__.
+   tracing and profiling, see the :doc:`../profile-manual/profile-manual`.
 
 -  *tools-sdk:* Installs a full SDK that runs on the device.
 
diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/ref-images.rst
index 0e26e57155..47beda0c23 100644
--- a/documentation/ref-manual/ref-images.rst
+++ b/documentation/ref-manual/ref-images.rst
@@ -24,12 +24,13 @@ image you want.
 
            1. Comment out the EXTRA_IMAGE_FEATURES line
            2. Set INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
-              
+
 
 From within the ``poky`` Git repository, you can use the following
 command to display the list of directories within the :term:`Source Directory`
-that contain image recipe files: $ ls
-meta*/recipes*/images/*.bb
+that contain image recipe files: ::
+
+   $ ls meta*/recipes*/images/*.bb
 
 Following is a list of supported recipes:
 
@@ -121,9 +122,8 @@ Following is a list of supported recipes:
    automated runtime testing. Provides a "known good" image that is
    deployed to a separate partition so that you can boot into it and use
    it to deploy a second image to be tested. You can find more
-   information about runtime testing in the "`Performing Automated
-   Runtime
-   Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+   information about runtime testing in the
+   ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
    section in the Yocto Project Development Tasks Manual.
 
 -  ``core-image-testmaster-initramfs``: A RAM-based Initial Root
@@ -132,8 +132,8 @@ Following is a list of supported recipes:
 
 -  ``core-image-weston``: A very basic Wayland image with a terminal.
    This image provides the Wayland protocol libraries and the reference
-   Weston compositor. For more information, see the "`Using Wayland and
-   Weston <&YOCTO_DOCS_DEV_URL;#dev-using-wayland-and-weston>`__"
+   Weston compositor. For more information, see the
+   ":ref:`dev-manual/dev-manual-common-tasks:using wayland and weston`"
    section in the Yocto Project Development Tasks Manual.
 
 -  ``core-image-x11``: A very basic X11 image with a terminal.
diff --git a/documentation/ref-manual/ref-kickstart.rst b/documentation/ref-manual/ref-kickstart.rst
index 271e6e8509..45222de05b 100644
--- a/documentation/ref-manual/ref-kickstart.rst
+++ b/documentation/ref-manual/ref-kickstart.rst
@@ -30,7 +30,13 @@ Command: part or partition
 ==========================
 
 Either of these commands creates a partition on the system and uses the
-following syntax: part [mntpoint] partition [mntpoint] If you do not
+following syntax:
+::
+
+   part [mntpoint] 
+   partition [mntpoint]
+
+If you do not
 provide mntpoint, Wic creates a partition but does not mount it.
 
 The ``mntpoint`` is where the partition is mounted and must be in one of
@@ -62,20 +68,19 @@ Here is an example that uses "/" as the mountpoint. The command uses
 Here is a list that describes other supported options you can use with
 the ``part`` and ``partition`` commands:
 
--  *``--size``:* The minimum partition size in MBytes. Specify an
+-  ``--size``: The minimum partition size in MBytes. Specify an
    integer value such as 500. Do not append the number with "MB". You do
    not need this option if you use ``--source``.
 
--  *``--fixed-size``:* The exact partition size in MBytes. You cannot
+-  ``--fixed-size``: The exact partition size in MBytes. You cannot
    specify with ``--size``. An error occurs when assembling the disk
    image if the partition data is larger than ``--fixed-size``.
 
--  *``--source``:* This option is a Wic-specific option that names the
+-  ``--source``: This option is a Wic-specific option that names the
    source of the data that populates the partition. The most common
    value for this option is "rootfs", but you can use any value that
    maps to a valid source plugin. For information on the source plugins,
-   see the "`Using the Wic Plugins
-   Interface <&YOCTO_DOCS_DEV_URL;#wic-using-the-wic-plugin-interface>`__"
+   see the ":ref:`dev-manual/dev-manual-common-tasks:using the wic plugin interface`"
    section in the Yocto Project Development Tasks Manual.
 
    If you use ``--source rootfs``, Wic creates a partition as large as
@@ -98,10 +103,10 @@ the ``part`` and ``partition`` commands:
    creates an empty partition. Consequently, you must use the ``--size``
    option to specify the size of the empty partition.
 
--  *``--ondisk`` or ``--ondrive``:* Forces the partition to be created
+-  ``--ondisk`` or ``--ondrive``: Forces the partition to be created
    on a particular disk.
 
--  *``--fstype``:* Sets the file system type for the partition. Valid
+-  ``--fstype``: Sets the file system type for the partition. Valid
    values are:
 
    -  ``ext4``
@@ -116,66 +121,66 @@ the ``part`` and ``partition`` commands:
 
    -  ``swap``
 
--  *``--fsoptions``:* Specifies a free-form string of options to be used
+-  ``--fsoptions``: Specifies a free-form string of options to be used
    when mounting the filesystem. This string is copied into the
    ``/etc/fstab`` file of the installed system and should be enclosed in
    quotes. If not specified, the default string is "defaults".
 
--  *``--label label``:* Specifies the label to give to the filesystem to
+-  ``--label label``: Specifies the label to give to the filesystem to
    be made on the partition. If the given label is already in use by
    another filesystem, a new label is created for the partition.
 
--  *``--active``:* Marks the partition as active.
+-  ``--active``: Marks the partition as active.
 
--  *``--align (in KBytes)``:* This option is a Wic-specific option that
+-  ``--align (in KBytes)``: This option is a Wic-specific option that
    says to start partitions on boundaries given x KBytes.
 
--  *``--no-table``:* This option is a Wic-specific option. Using the
+-  ``--no-table``: This option is a Wic-specific option. Using the
    option reserves space for the partition and causes it to become
    populated. However, the partition is not added to the partition
    table.
 
--  *``--exclude-path``:* This option is a Wic-specific option that
+-  ``--exclude-path``: This option is a Wic-specific option that
    excludes the given relative path from the resulting image. This
    option is only effective with the rootfs source plugin.
 
--  *``--extra-space``:* This option is a Wic-specific option that adds
+-  ``--extra-space``: This option is a Wic-specific option that adds
    extra space after the space filled by the content of the partition.
    The final size can exceed the size specified by the ``--size``
    option. The default value is 10 Mbytes.
 
--  *``--overhead-factor``:* This option is a Wic-specific option that
+-  ``--overhead-factor``: This option is a Wic-specific option that
    multiplies the size of the partition by the option's value. You must
    supply a value greater than or equal to "1". The default value is
    "1.3".
 
--  *``--part-name``:* This option is a Wic-specific option that
+-  ``--part-name``: This option is a Wic-specific option that
    specifies a name for GPT partitions.
 
--  *``--part-type``:* This option is a Wic-specific option that
+-  ``--part-type``: This option is a Wic-specific option that
    specifies the partition type globally unique identifier (GUID) for
    GPT partitions. You can find the list of partition type GUIDs at
    http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs.
 
--  *``--use-uuid``:* This option is a Wic-specific option that causes
+-  ``--use-uuid``: This option is a Wic-specific option that causes
    Wic to generate a random GUID for the partition. The generated
    identifier is used in the bootloader configuration to specify the
    root partition.
 
--  *``--uuid``:* This option is a Wic-specific option that specifies the
+-  ``--uuid``: This option is a Wic-specific option that specifies the
    partition UUID.
 
--  *``--fsuuid``:* This option is a Wic-specific option that specifies
+-  ``--fsuuid``: This option is a Wic-specific option that specifies
    the filesystem UUID. You can generate or modify
    :term:`WKS_FILE` with this option if a preconfigured
    filesystem UUID is added to the kernel command line in the bootloader
    configuration before you run Wic.
 
--  *``--system-id``:* This option is a Wic-specific option that
+-  ``--system-id``: This option is a Wic-specific option that
    specifies the partition system ID, which is a one byte long,
    hexadecimal parameter with or without the 0x prefix.
 
--  *``--mkfs-extraopts``:* This option specifies additional options to
+-  ``--mkfs-extraopts``: This option specifies additional options to
    pass to the ``mkfs`` utility. Some default options for certain
    filesystems do not take effect. See Wic's help on kickstart (i.e.
    ``wic help kickstart``).
@@ -195,13 +200,13 @@ supports the following options:
    command essentially provides a means of modifying bootloader
    configuration.
 
--  *``--timeout``:* Specifies the number of seconds before the
+-  ``--timeout``: Specifies the number of seconds before the
    bootloader times out and boots the default option.
 
--  *``--append``:* Specifies kernel parameters. These parameters will be
+-  ``--append``: Specifies kernel parameters. These parameters will be
    added to the syslinux ``APPEND`` or ``grub`` kernel command line.
 
--  *``--configfile``:* Specifies a user-defined configuration file for
+-  ``--configfile``: Specifies a user-defined configuration file for
    the bootloader. You can provide a full pathname for the file or a
    file that exists in the ``canned-wks`` folder. This option overrides
    all other bootloader options.
diff --git a/documentation/ref-manual/ref-qa-checks.rst b/documentation/ref-manual/ref-qa-checks.rst
index a56de690b1..3e76ac1509 100644
--- a/documentation/ref-manual/ref-qa-checks.rst
+++ b/documentation/ref-manual/ref-qa-checks.rst
@@ -209,7 +209,10 @@ Errors and Warnings
    Typically, the way to solve this performance issue is to add "-fPIC"
    or "-fpic" to the compiler command-line options. For example, given
    software that reads :term:`CFLAGS` when you build it,
-   you could add the following to your recipe: CFLAGS_append = " -fPIC "
+   you could add the following to your recipe:
+   ::
+
+      CFLAGS_append = " -fPIC "
 
    For more information on text relocations at runtime, see
    http://www.akkadia.org/drepper/textrelocs.html.
@@ -224,7 +227,10 @@ Errors and Warnings
    variable is being passed to the linker command. A common workaround
    for this situation is to pass in ``LDFLAGS`` using
    :term:`TARGET_CC_ARCH` within the recipe as
-   follows: TARGET_CC_ARCH += "${LDFLAGS}"
+   follows:
+   ::
+
+      TARGET_CC_ARCH += "${LDFLAGS}"
 
     
 
@@ -244,10 +250,11 @@ Errors and Warnings
 
    The ``/usr/share/info/dir`` should not be packaged. Add the following
    line to your :ref:`ref-tasks-install` task or to your
-   ``do_install_append`` within the recipe as follows: rm
-   ${D}${infodir}/dir
+   ``do_install_append`` within the recipe as follows:
+   ::
 
-    
+      rm ${D}${infodir}/dir
+   
 
 -  ``Symlink <path> in <packagename> points to TMPDIR [symlink-to-sysroot]``
 
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst
index 7b33c0ae6b..be041e7254 100644
--- a/documentation/ref-manual/ref-release-process.rst
+++ b/documentation/ref-manual/ref-release-process.rst
@@ -17,8 +17,13 @@ month cadence roughly timed each April and October of the year.
 Following are examples of some major YP releases with their codenames
 also shown. See the "`Major Release
 Codenames <#major-release-codenames>`__" section for information on
-codenames used with major releases. 2.2 (Morty) 2.1 (Krogoth) 2.0
-(Jethro) While the cadence is never perfect, this timescale facilitates
+codenames used with major releases.
+
+  - 2.2 (Morty) 
+  - 2.1 (Krogoth)
+  - 2.0 (Jethro) 
+
+While the cadence is never perfect, this timescale facilitates
 regular releases that have strong QA cycles while not overwhelming users
 with too many new releases. The cadence is predictable and avoids many
 major holidays in various geographies.
@@ -26,7 +31,13 @@ major holidays in various geographies.
 The Yocto project delivers minor (point) releases on an unscheduled
 basis and are usually driven by the accumulation of enough significant
 fixes or enhancements to the associated major release. Following are
-some example past point releases: 2.1.1 2.1.2 2.2.1 The point release
+some example past point releases:
+
+  - 2.1.1
+  - 2.1.2
+  - 2.2.1 
+
+The point release
 indicates a point in the major release branch where a full QA cycle and
 release process validates the content of the new branch.
 
@@ -39,9 +50,8 @@ Major Release Codenames
 =======================
 
 Each major release receives a codename that identifies the release in
-the `Yocto Project Source
-Repositories <&YOCTO_DOCS_OM_URL;#yocto-project-repositories>`__. The
-concept is that branches of :term:`Metadata` with the same
+the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
+The concept is that branches of :term:`Metadata` with the same
 codename are likely to be compatible and thus work together.
 
 .. note::
@@ -95,9 +105,8 @@ provide the Yocto Project team a way to ensure a release is validated.
 Additionally, because the test strategies are visible to you as a
 developer, you can validate your projects. This section overviews the
 available test infrastructure used in the Yocto Project. For information
-on how to run available tests on your projects, see the "`Performing
-Automated Runtime
-Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+on how to run available tests on your projects, see the
+":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 The QA/testing infrastructure is woven into the project to the point
@@ -119,12 +128,12 @@ consists of the following pieces:
 
 -  :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
    performs runtime testing of images after they are built. The tests
-   are usually used with `QEMU <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__
+   are usually used with :doc:`QEMU <../dev-manual/dev-manual-qemu>`
    to boot the images and check the combined runtime result boot
    operation and functions. However, the test can also use the IP
    address of a machine to test.
 
--  ```ptest`` <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__:
+-  :ref:`ptest <dev-manual/dev-manual-common-tasks:testing packages with ptest>`:
    Runs tests against packages produced during the build for a given
    piece of software. The test allows the packages to be be run within a
    target image.
@@ -147,7 +156,7 @@ effort has been made to automate the tests so that more people can use
 them and the Yocto Project development team can run them faster and more
 efficiently.
 
-The Yocto Project's main Autobuilder (``autobuilder.yoctoproject.org``)
+The Yocto Project's main Autobuilder (https://autobuilder.yoctoproject.org/)
 publicly tests each Yocto Project release's code in the
 :term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing
 occurs for both the current state of the "master" branch and also for
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index 1efb81414f..48a443331b 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -11,8 +11,8 @@ describes the Source Directory and gives information about those files
 and directories.
 
 For information on how to establish a local Source Directory on your
-development system, see the "`Locating Yocto Project Source
-Files <&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files>`__"
+development system, see the
+":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
 section in the Yocto Project Development Tasks Manual.
 
 .. note::
@@ -42,7 +42,7 @@ itself; consequently, most users do not need to worry about BitBake.
 
 When you run the ``bitbake`` command, the main BitBake executable (which
 resides in the ``bitbake/bin/`` directory) starts. Sourcing the
-environment setup script (i.e. ````` <#structure-core-script>`__) places
+environment setup script (i.e. :ref:`structure-core-script`) places
 the ``scripts/`` and ``bitbake/bin/`` directories (in that order) into
 the shell's ``PATH`` environment variable.
 
@@ -59,14 +59,14 @@ generated by the OpenEmbedded build system in its standard configuration
 where the source tree is combined with the output. The :term:`Build Directory`
 is created initially when you ``source``
 the OpenEmbedded build environment setup script (i.e.
-````` <#structure-core-script>`__).
+:ref:`structure-core-script`).
 
 It is also possible to place output and configuration files in a
 directory separate from the :term:`Source Directory` by
 providing a directory name when you ``source`` the setup script. For
 information on separating output from your local Source Directory files
 (commonly described as an "out of tree" build), see the
-"````` <#structure-core-script>`__" section.
+":ref:`structure-core-script`" section.
 
 .. _handbook:
 
@@ -103,9 +103,8 @@ metadata to define the Poky reference distribution.
 -------------------
 
 This directory contains the Yocto Project reference hardware Board
-Support Packages (BSPs). For more information on BSPs, see the `Yocto
-Project Board Support Package (BSP) Developer's
-Guide <&YOCTO_DOCS_BSP_URL;>`__.
+Support Packages (BSPs). For more information on BSPs, see the
+:doc:`../bsp-guide/bsp-guide`.
 
 .. _structure-meta-selftest:
 
@@ -131,7 +130,7 @@ This directory contains template recipes for BSP and kernel development.
 
 This directory contains various integration scripts that implement extra
 functionality in the Yocto Project environment (e.g. QEMU scripts). The
-````` <#structure-core-script>`__ script prepends this directory to the
+:ref:`structure-core-script` script prepends this directory to the
 shell's ``PATH`` environment variable.
 
 The ``scripts`` directory has useful scripts that assist in contributing
@@ -154,18 +153,30 @@ When you run this script, your Yocto Project environment is set up, a
 :term:`Build Directory` is created, your working
 directory becomes the Build Directory, and you are presented with some
 simple suggestions as to what to do next, including a list of some
-possible targets to build. Here is an example: $ source
-oe-init-build-env ### Shell environment set up for builds. ### You can
-now run 'bitbake <target>' Common targets are: core-image-minimal
-core-image-sato meta-toolchain meta-ide-support You can also run
-generated qemu images with a command like 'runqemu qemux86-64' The
-default output of the ``oe-init-build-env`` script is from the
+possible targets to build. Here is an example:
+::
+
+   $ source oe-init-build-env
+
+   ### Shell environment set up for builds. ###
+
+   You can now run 'bitbake <target>'
+
+   Common targets are:
+       core-image-minimal
+       core-image-sato
+       meta-toolchain
+       meta-ide-support
+
+   You can also run generated qemu images with a command like 'runqemu qemux86-64'
+
+The default output of the ``oe-init-build-env`` script is from the
 ``conf-notes.txt`` file, which is found in the ``meta-poky`` directory
 within the :term:`Source Directory`. If you design a
 custom distribution, you can include your own version of this
 configuration file to mention the targets defined by your distribution.
-See the "`Creating a Custom Template Configuration
-Directory <&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory>`__"
+See the
+":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`"
 section in the Yocto Project Development Tasks Manual for more
 information.
 
@@ -175,11 +186,14 @@ you provide a Build Directory argument when you ``source`` the script,
 you direct the OpenEmbedded build system to create a Build Directory of
 your choice. For example, the following command creates a Build
 Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`:
-$ source OE_INIT_FILE ~/mybuilds The
-OpenEmbedded build system uses the template configuration files, which
+::
+
+   $ source OE_INIT_FILE ~/mybuilds
+
+The OpenEmbedded build system uses the template configuration files, which
 are found by default in the ``meta-poky/conf/`` directory in the Source
-Directory. See the "`Creating a Custom Template Configuration
-Directory <&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory>`__"
+Directory. See the
+":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`"
 section in the Yocto Project Development Tasks Manual for more
 information.
 
@@ -207,7 +221,7 @@ The Build Directory - ``build/``
 
 The OpenEmbedded build system creates the :term:`Build Directory`
 when you run the build environment setup
-script ````` <#structure-core-script>`__. If you do not give the Build
+script :ref:`structure-core-script`. If you do not give the Build
 Directory a specific name when you run the setup script, the name
 defaults to ``build/``.
 
@@ -223,8 +237,7 @@ The OpenEmbedded build system creates this directory when you enable
 build history via the ``buildhistory`` class file. The directory
 organizes build information into image, packages, and SDK
 subdirectories. For information on the build history feature, see the
-"`Maintaining Build Output
-Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__"
+":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _structure-build-conf-local.conf:
@@ -248,7 +261,7 @@ which you want to access downloaded files (``DL_DIR``).
 If ``local.conf`` is not present when you start the build, the
 OpenEmbedded build system creates it from ``local.conf.sample`` when you
 ``source`` the top-level build environment setup script
-````` <#structure-core-script>`__.
+:ref:`structure-core-script`.
 
 The source ``local.conf.sample`` file used depends on the
 ``$TEMPLATECONF`` script variable, which defaults to ``meta-poky/conf/``
@@ -258,7 +271,11 @@ environment. Because the script variable points to the source of the
 ``local.conf.sample`` file, this implies that you can configure your
 build environment from any layer by setting the variable in the
 top-level build environment setup script as follows:
-TEMPLATECONF=your_layer/conf Once the build process gets the sample
+::
+
+   TEMPLATECONF=your_layer/conf
+
+Once the build process gets the sample
 file, it uses ``sed`` to substitute final
 ``${``\ :term:`OEROOT`\ ``}`` values for all
 ``##OEROOT##`` values.
@@ -283,7 +300,7 @@ file, it uses ``sed`` to substitute final
 ----------------------------
 
 This configuration file defines
-`layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__,
+:ref:`layers <dev-manual/dev-manual-common-tasks:understanding and creating layers>`,
 which are directory trees, traversed (or walked) by BitBake. The
 ``bblayers.conf`` file uses the :term:`BBLAYERS`
 variable to list the layers BitBake tries to find.
@@ -291,7 +308,7 @@ variable to list the layers BitBake tries to find.
 If ``bblayers.conf`` is not present when you start the build, the
 OpenEmbedded build system creates it from ``bblayers.conf.sample`` when
 you ``source`` the top-level build environment setup script (i.e.
-````` <#structure-core-script>`__).
+:ref:`structure-core-script`).
 
 As with the ``local.conf`` file, the source ``bblayers.conf.sample``
 file used depends on the ``$TEMPLATECONF`` script variable, which
@@ -301,10 +318,12 @@ building from the OpenEmbedded-Core environment. Because the script
 variable points to the source of the ``bblayers.conf.sample`` file, this
 implies that you can base your build from any layer by setting the
 variable in the top-level build environment setup script as follows:
-TEMPLATECONF=your_layer/conf Once the build process gets the sample
-file, it uses ``sed`` to substitute final
-``${``\ :term:`OEROOT`\ ``}`` values for all
-``##OEROOT##`` values.
+::
+
+   TEMPLATECONF=your_layer/conf
+
+Once the build process gets the sample file, it uses ``sed`` to substitute final
+``${``\ :term:`OEROOT`\ ``}`` values for all ``##OEROOT##`` values.
 
 .. note::
 
@@ -395,9 +414,8 @@ This directory contains any "end result" output from the OpenEmbedded
 build process. The :term:`DEPLOY_DIR` variable points
 to this directory. For more detail on the contents of the ``deploy``
 directory, see the
-"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" and
-"`Application Development
-SDK <&YOCTO_DOCS_OM_URL;#sdk-dev-environment>`__" sections in the Yocto
+":ref:`images-dev-environment`" and
+":ref:`sdk-dev-environment`" sections in the Yocto
 Project Overview and Concepts Manual.
 
 .. _structure-build-tmp-deploy-deb:
@@ -434,9 +452,8 @@ This directory receives package licensing information. For example, the
 directory contains sub-directories for ``bash``, ``busybox``, and
 ``glibc`` (among others) that in turn contain appropriate ``COPYING``
 license files with other licensing information. For information on
-licensing, see the "`Maintaining Open Source License Compliance During
-Your Product's
-Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__"
+licensing, see the
+":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _structure-build-tmp-deploy-images:
@@ -461,8 +478,11 @@ image again.
 If you do accidentally delete files here, you will need to force them to
 be re-created. In order to do that, you will need to know the target
 that produced them. For example, these commands rebuild and re-create
-the kernel files: $ bitbake -c clean virtual/kernel $ bitbake
-virtual/kernel
+the kernel files:
+::
+
+   $ bitbake -c clean virtual/kernel
+   $ bitbake virtual/kernel
 
 .. _structure-build-tmp-deploy-sdk:
 
@@ -472,8 +492,7 @@ virtual/kernel
 The OpenEmbedded build system creates this directory to hold toolchain
 installer scripts which, when executed, install the sysroot that matches
 your target hardware. You can find out more about these installers in
-the "`Building an SDK
-Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__"
+the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual.
 
@@ -540,8 +559,8 @@ the files in the directory are empty of data, BitBake uses the filenames
 and timestamps for tracking purposes.
 
 For information on how BitBake uses stamp files to determine if a task
-should be rerun, see the "`Stamp Files and the Rerunning of
-Tasks <&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks>`__"
+should be rerun, see the
+":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _structure-build-tmp-log:
@@ -573,8 +592,7 @@ built within the Yocto Project. For this package, a work directory of
 ``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
 to as the ``WORKDIR``, is created. Within this directory, the source is
 unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
-(See the "`Using Quilt in Your
-Workflow <&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow>`__" section in
+(See the ":ref:`using-a-quilt-workflow`" section in
 the Yocto Project Development Tasks Manual for more information.) Within
 the ``linux-qemux86-standard-build`` directory, standard Quilt
 directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and
diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst
index b82bed8a76..56218e4ebb 100644
--- a/documentation/ref-manual/ref-system-requirements.rst
+++ b/documentation/ref-manual/ref-system-requirements.rst
@@ -14,18 +14,15 @@ descriptions, and so forth as needed during the course of using the
 Yocto Project.
 
 For introductory information on the Yocto Project, see the
-:yocto_home:`Yocto Project Website <>` and the "`Yocto Project
-Development
-Environment <&YOCTO_DOCS_OM_URL;#overview-development-environment>`__"
+:yocto_home:`Yocto Project Website <>` and the
+":ref:`overview-manual/overview-manual-development-environment:the yocto project development environment`"
 chapter in the Yocto Project Overview and Concepts Manual.
 
 If you want to use the Yocto Project to quickly build an image without
-having to understand concepts, work through the `Yocto Project Quick
-Build <&YOCTO_DOCS_BRIEF_URL;>`__ document. You can find "how-to"
-information in the `Yocto Project Development Tasks
-Manual <&YOCTO_DOCS_DEV_URL;>`__. You can find Yocto Project overview
-and conceptual information in the `Yocto Project Overview and Concepts
-Manual <&YOCTO_DOCS_OM_URL;>`__.
+having to understand concepts, work through the
+:doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document. You can find "how-to"
+information in the :doc:`../dev-manual/dev-manual`. You can find Yocto Project overview
+and conceptual information in the :doc:`../overview-manual/overview-manual`.
 
 .. note::
 
@@ -95,12 +92,11 @@ distributions:
       WSLv2, if you still decide to use WSL please upgrade to WSLv2.
 
    -  If you encounter problems, please go to `Yocto Project
-      Bugzilla <&YOCTO_BUGZILLA_URL;>`__ and submit a bug. We are
+      Bugzilla <http://bugzilla.yoctoproject.org>`__ and submit a bug. We are
       interested in hearing about your experience. For information on
       how to submit a bug, see the Yocto Project
       :yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
-      and the "`Submitting a Defect Against the Yocto
-      Project <&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project>`__"
+      and the ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`"
       section in the Yocto Project Development Tasks Manual.
 
 
@@ -126,19 +122,28 @@ supported Ubuntu or Debian Linux distribution:
       might experience QEMU build failures due to the package installing
       its own custom ``/usr/include/linux/soundcard.h`` on the Debian
       system. If you run into this situation, either of the following
-      solutions exist: $ sudo apt-get build-dep qemu $ sudo apt-get
-      remove oss4-dev
+      solutions exist:
+      ::
+
+         $ sudo apt-get build-dep qemu
+         $ sudo apt-get remove oss4-dev
 
    -  For Debian-8, ``python3-git`` and ``pylint3`` are no longer
-      available via ``apt-get``. $ sudo pip3 install GitPython
-      pylint==1.9.5
+      available via ``apt-get``.
+      ::
+
+         $ sudo pip3 install GitPython pylint==1.9.5
 
 -  *Essentials:* Packages needed to build an image on a headless system:
-   $ sudo apt-get install UBUNTU_HOST_PACKAGES_ESSENTIAL
+   ::
+
+      $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
 
 -  *Documentation:* Packages needed if you are going to build out the
-   Yocto Project documentation manuals: $ sudo apt-get install make
-   xsltproc docbook-utils fop dblatex xmlto
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
 
 Fedora Packages
 ---------------
@@ -147,12 +152,17 @@ The following list shows the required packages by function given a
 supported Fedora Linux distribution:
 
 -  *Essentials:* Packages needed to build an image for a headless
-   system: $ sudo dnf install FEDORA_HOST_PACKAGES_ESSENTIAL
+   system:
+   ::
+
+      $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL;
 
 -  *Documentation:* Packages needed if you are going to build out the
-   Yocto Project documentation manuals: $ sudo dnf install
-   docbook-style-dsssl docbook-style-xsl \\ docbook-dtds docbook-utils
-   fop libxslt dblatex xmlto
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo dnf install  docbook-style-dsssl docbook-style-xsl \
+      docbook-dtds docbook-utils fop libxslt dblatex xmlto
 
 openSUSE Packages
 -----------------
@@ -161,7 +171,10 @@ The following list shows the required packages by function given a
 supported openSUSE Linux distribution:
 
 -  *Essentials:* Packages needed to build an image for a headless
-   system: $ sudo zypper install OPENSUSE_HOST_PACKAGES_ESSENTIAL
+   system:
+   ::
+
+      $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
 
 -  *Documentation:* Packages needed if you are going to build out the
    Yocto Project documentation manuals: $ sudo zypper install dblatex
@@ -174,7 +187,10 @@ The following list shows the required packages by function given a
 supported CentOS-7 Linux distribution:
 
 -  *Essentials:* Packages needed to build an image for a headless
-   system: $ sudo yum install CENTOS7_HOST_PACKAGES_ESSENTIAL
+   system:
+   ::
+
+      $ sudo yum install &CENTOS7_HOST_PACKAGES_ESSENTIAL;
 
    .. note::
 
@@ -187,9 +203,11 @@ supported CentOS-7 Linux distribution:
          ``epel-release``.
 
 -  *Documentation:* Packages needed if you are going to build out the
-   Yocto Project documentation manuals: $ sudo yum install
-   docbook-style-dsssl docbook-style-xsl \\ docbook-dtds docbook-utils
-   fop libxslt dblatex xmlto
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo yum install docbook-style-dsssl docbook-style-xsl \
+      docbook-dtds docbook-utils fop libxslt dblatex xmlto
 
 CentOS-8 Packages
 -----------------
@@ -198,7 +216,10 @@ The following list shows the required packages by function given a
 supported CentOS-8 Linux distribution:
 
 -  *Essentials:* Packages needed to build an image for a headless
-   system: $ sudo dnf install CENTOS8_HOST_PACKAGES_ESSENTIAL
+   system:
+   ::
+
+      $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL;
 
    .. note::
 
@@ -214,9 +235,11 @@ supported CentOS-8 Linux distribution:
          ``epel-release``.
 
 -  *Documentation:* Packages needed if you are going to build out the
-   Yocto Project documentation manuals: $ sudo dnf install
-   docbook-style-dsssl docbook-style-xsl \\ docbook-dtds docbook-utils
-   fop libxslt dblatex xmlto
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo dnf install docbook-style-dsssl docbook-style-xsl \\
+      docbook-dtds docbook-utils fop libxslt dblatex xmlto
 
 Required Git, tar, Python and gcc Versions
 ==========================================
@@ -251,10 +274,14 @@ The ``install-buildtools`` script is the easiest of the three methods by
 which you can get these tools. It downloads a pre-built buildtools
 installer and automatically installs the tools for you:
 
-1. Execute the ``install-buildtools`` script. Here is an example: $ cd
-   poky $ scripts/install-buildtools --without-extended-buildtools \\
-   --base-url https://downloads.yoctoproject.org/releases/yocto \\ --release yocto-DISTRO \\
-   --installer-version DISTRO
+1. Execute the ``install-buildtools`` script. Here is an example:
+   ::
+
+      $ cd poky
+      $ scripts/install-buildtools --without-extended-buildtools \
+        --base-url https://downloads.yoctoproject.org/releases/yocto \
+        --release yocto-&DISTRO; \
+        --installer-version &DISTRO;
 
    During execution, the buildtools tarball will be downloaded, the
    checksum of the download will be verified, the installer will be run
@@ -263,17 +290,25 @@ installer and automatically installs the tools for you:
 
    To avoid the need of ``sudo`` privileges, the ``install-buildtools``
    script will by default tell the installer to install in:
-   /path/to/poky/buildtools
+   ::
+
+      /path/to/poky/buildtools
 
    If your host development system needs the additional tools provided
    in the ``buildtools-extended`` tarball, you can instead execute the
-   ``install-buildtools`` script with the default parameters: $ cd poky
-   $ scripts/install-buildtools
+   ``install-buildtools`` script with the default parameters:
+   ::
+
+      $ cd poky
+      $ scripts/install-buildtools
 
 2. Source the tools environment setup script by using a command like the
-   following: $ source
-   /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux Of
-   course, you need to supply your installation directory and be sure to
+   following:
+   ::
+
+      $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux
+
+   Of course, you need to supply your installation directory and be sure to
    use the right file (i.e. i586 or x86_64).
 
    After you have sourced the setup script, the tools are added to
@@ -290,21 +325,30 @@ Downloading a Pre-Built ``buildtools`` Tarball
 Downloading and running a pre-built buildtools installer is the easiest
 of the two methods by which you can get these tools:
 
-1. Locate and download the ``*.sh`` at
-   ` <&YOCTO_RELEASE_DL_URL;/buildtools/>`__.
+1. Locate and download the ``*.sh`` at &YOCTO_RELEASE_DL_URL;/buildtools/
 
 2. Execute the installation script. Here is an example for the
-   traditional installer: $ sh
-   ~/Downloads/x86_64-buildtools-nativesdk-standalone-DISTRO.sh Here is
-   an example for the extended installer: $ sh
-   ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-DISTRO.sh
+   traditional installer:
+   ::
+
+      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-DISTRO.sh
+
+   Here is an example for the extended installer:
+   ::
+
+      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-DISTRO.sh
+
    During execution, a prompt appears that allows you to choose the
    installation directory. For example, you could choose the following:
    /home/your-username/buildtools
 
 3. Source the tools environment setup script by using a command like the
-   following: $ source
-   /home/your_username/buildtools/environment-setup-i586-poky-linux Of
+   following:
+   ::
+
+      $ source /home/your_username/buildtools/environment-setup-i586-poky-linux
+
+   Of
    course, you need to supply your installation directory and be sure to
    use the right file (i.e. i585 or x86-64).
 
@@ -330,11 +374,17 @@ installer:
 
 1. On the machine that is able to run BitBake, be sure you have set up
    your build environment with the setup script
-   (````` <#structure-core-script>`__).
+   (:ref:`structure-core-script`).
+
+2. Run the BitBake command to build the tarball:
+   ::
+
+      $ bitbake buildtools-tarball
 
-2. Run the BitBake command to build the tarball: $ bitbake
-   buildtools-tarball or run the BitBake command to build the extended
-   tarball: $ bitbake buildtools-extended-tarball
+   or run the BitBake command to build the extended tarball:
+   ::
+
+      $ bitbake buildtools-extended-tarball
 
    .. note::
 
@@ -355,18 +405,27 @@ installer:
 
 4. On the machine that does not meet the requirements, run the ``.sh``
    file to install the tools. Here is an example for the traditional
-   installer: $ sh
-   ~/Downloads/x86_64-buildtools-nativesdk-standalone-DISTRO.sh Here is
-   an example for the extended installer: $ sh
-   ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-DISTRO.sh
+   installer:
+   ::
+
+      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
+
+   Here is an example for the extended installer:
+   ::
+
+      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
+
    During execution, a prompt appears that allows you to choose the
    installation directory. For example, you could choose the following:
    /home/your_username/buildtools
 
 5. Source the tools environment setup script by using a command like the
-   following: $ source
-   /home/your_username/buildtools/environment-setup-x86_64-poky-linux Of
-   course, you need to supply your installation directory and be sure to
+   following:
+   ::
+
+      $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux
+
+   Of course, you need to supply your installation directory and be sure to
    use the right file (i.e. i586 or x86_64).
 
    After you have sourced the setup script, the tools are added to
diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst
index 5b0711586f..44463f2236 100644
--- a/documentation/ref-manual/ref-tasks.rst
+++ b/documentation/ref-manual/ref-tasks.rst
@@ -109,7 +109,7 @@ after other tasks works the same way.
    ::
 
            do_build[recrdeptask] += "do_deploy"
-                      
+
 
    See the "
    Dependencies
@@ -143,8 +143,7 @@ The ``do_image`` task performs pre-processing on the image through the
 :term:`IMAGE_PREPROCESS_COMMAND` and
 dynamically generates supporting ``do_image_*`` tasks as needed.
 
-For more information on image creation, see the "`Image
-Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__"
+For more information on image creation, see the ":ref:`image-generation-dev-environment`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-image-complete:
@@ -162,8 +161,8 @@ The ``do_image_complete`` task performs post-processing on the image
 through the
 :term:`IMAGE_POSTPROCESS_COMMAND`.
 
-For more information on image creation, see the "`Image
-Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__"
+For more information on image creation, see the
+":ref:`image-generation-dev-environment`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-install:
@@ -176,10 +175,9 @@ Copies files that are to be packaged into the holding area
 working directory set to ``${``\ :term:`B`\ ``}``, which is the
 compilation directory. The ``do_install`` task, as well as other tasks
 that either directly or indirectly depend on the installed files (e.g.
-:ref:`ref-tasks-package`,
-```do_package_write_*`` <#ref-tasks-package_write_deb>`__, and
+:ref:`ref-tasks-package`, ``do_package_write_*``, and
 :ref:`ref-tasks-rootfs`), run under
-`fakeroot <&YOCTO_DOCS_OM_URL;#fakeroot-and-pseudo>`__.
+:ref:`fakeroot <overview-manual/overview-manual-concepts:fakeroot and pseudo>`.
 
 .. note::
 
@@ -187,9 +185,8 @@ that either directly or indirectly depend on the installed files (e.g.
    of the installed files to unintended values. Some methods of copying
    files, notably when using the recursive ``cp`` command, can preserve
    the UID and/or GID of the original file, which is usually not what
-   you want. The
-   ```host-user-contaminated`` <#insane-host-user-contaminated>`__ QA
-   check checks for files that probably have the wrong ownership.
+   you want. The ``host-user-contaminated`` QA check checks for files
+   that probably have the wrong ownership.
 
    Safe methods for installing files include the following:
 
@@ -223,9 +220,8 @@ variables.
 The ``do_package`` task, in conjunction with the
 :ref:`ref-tasks-packagedata` task, also saves some
 important package metadata. For additional information, see the
-:term:`PKGDESTWORK` variable and the "`Automatically
-Added Runtime
-Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+:term:`PKGDESTWORK` variable and the
+":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-package_qa:
@@ -243,8 +239,8 @@ see the :ref:`insane <ref-classes-insane>` class.
 
 Creates Debian packages (i.e. ``*.deb`` files) and places them in the
 ``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory in
-the package feeds area. For more information, see the "`Package
-Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in
+the package feeds area. For more information, see the
+":ref:`package-feeds-dev-environment`" section in
 the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-package_write_ipk:
@@ -254,8 +250,8 @@ the Yocto Project Overview and Concepts Manual.
 
 Creates IPK packages (i.e. ``*.ipk`` files) and places them in the
 ``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory in
-the package feeds area. For more information, see the "`Package
-Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in
+the package feeds area. For more information, see the
+":ref:`package-feeds-dev-environment`" section in
 the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-package_write_rpm:
@@ -265,8 +261,8 @@ the Yocto Project Overview and Concepts Manual.
 
 Creates RPM packages (i.e. ``*.rpm`` files) and places them in the
 ``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory in
-the package feeds area. For more information, see the "`Package
-Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in
+the package feeds area. For more information, see the
+":ref:`package-feeds-dev-environment`" section in
 the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-package_write_tar:
@@ -276,8 +272,8 @@ the Yocto Project Overview and Concepts Manual.
 
 Creates tarballs and places them in the
 ``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory in
-the package feeds area. For more information, see the "`Package
-Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in
+the package feeds area. For more information, see the
+":ref:`package-feeds-dev-environment`" section in
 the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-packagedata:
@@ -312,8 +308,14 @@ and kept in a subdirectory of the directory holding the recipe file. For
 example, consider the
 :yocto_git:`bluez5 </cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/bluez5>`
 recipe from the OE-Core layer (i.e. ``poky/meta``):
-poky/meta/recipes-connectivity/bluez5 This recipe has two patch files
-located here: poky/meta/recipes-connectivity/bluez5/bluez5
+::
+
+   poky/meta/recipes-connectivity/bluez5
+
+This recipe has two patch files located here:
+::
+
+   poky/meta/recipes-connectivity/bluez5/bluez5
 
 In the ``bluez5`` recipe, the ``SRC_URI`` statements point to the source
 and patch files needed to build the package.
@@ -331,23 +333,35 @@ and patch files needed to build the package.
 As mentioned earlier, the build system treats files whose file types are
 ``.patch`` and ``.diff`` as patch files. However, you can use the
 "apply=yes" parameter with the ``SRC_URI`` statement to indicate any
-file as a patch file: SRC_URI = " \\ git://path_to_repo/some_package \\
-file://file;apply=yes \\ "
+file as a patch file:
+::
+
+   SRC_URI = " \\
+       git://path_to_repo/some_package \\
+       file://file;apply=yes \\
+       "
 
 Conversely, if you have a directory full of patch files and you want to
 exclude some so that the ``do_patch`` task does not apply them during
 the patch phase, you can use the "apply=no" parameter with the
-``SRC_URI`` statement: SRC_URI = " \\ git://path_to_repo/some_package \\
-file://path_to_lots_of_patch_files \\
-file://path_to_lots_of_patch_files/patch_file5;apply=no \\ " In the
+``SRC_URI`` statement:
+::
+
+   SRC_URI = " \
+       git://path_to_repo/some_package \
+       file://path_to_lots_of_patch_files \
+       file://path_to_lots_of_patch_files/patch_file5;apply=no \
+       "
+
+In the
 previous example, assuming all the files in the directory holding the
 patch files end with either ``.patch`` or ``.diff``, every file would be
 applied as a patch by default except for the patch_file5 patch.
 
 You can find out more about the patching process in the
-"`Patching <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__" section in
-the Yocto Project Overview and Concepts Manual and the "`Patching
-Code <&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code>`__" section in the
+":ref:`patching-dev-environment`" section in
+the Yocto Project Overview and Concepts Manual and the
+":ref:`new-recipe-patching-code`" section in the
 Yocto Project Development Tasks Manual.
 
 .. _ref-tasks-populate_lic:
@@ -364,8 +378,7 @@ the image is constructed.
 -------------------
 
 Creates the file and directory structure for an installable SDK. See the
-"`SDK
-Generation <&YOCTO_DOCS_OM_URL;#sdk-generation-dev-environment>`__"
+":ref:`sdk-generation-dev-environment`"
 section in the Yocto Project Overview and Concepts Manual for more
 information.
 
@@ -420,8 +433,7 @@ Unpacks the source code into a working directory pointed to by
 ``${``\ :term:`WORKDIR`\ ``}``. The :term:`S`
 variable also plays a role in where unpacked source files ultimately
 reside. For more information on how source files are unpacked, see the
-"`Source
-Fetching <&YOCTO_DOCS_OM_URL;#source-fetching-dev-environment>`__"
+":ref:`source-fetching-dev-environment`"
 section in the Yocto Project Overview and Concepts Manual and also see
 the ``WORKDIR`` and ``S`` variable descriptions.
 
@@ -442,16 +454,24 @@ of the recipe exists upstream and a status of not updated, updated, or
 unknown.
 
 To check the upstream version and status of a recipe, use the following
-devtool commands: $ devtool latest-version $ devtool
-check-upgrade-status See the "```devtool`` Quick
-Reference <#ref-devtool-reference>`__" chapter for more information on
-``devtool``. See the "`Checking on the Upgrade Status of a
-Recipe <&YOCTO_DOCS_REF_URL;#devtool-checking-on-the-upgrade-status-of-a-recipe>`__"
+devtool commands:
+::
+
+   $ devtool latest-version
+   $ devtool check-upgrade-status
+
+See the ":ref:`ref-manual/ref-devtool-reference:\`\`devtool\`\` quick reference`"
+chapter for more information on
+``devtool``. See the ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`"
 section for information on checking the upgrade status of a recipe.
 
 To build the ``checkpkg`` task, use the ``bitbake`` command with the
-"-c" option and task name: $ bitbake core-image-minimal -c checkpkg By
-default, the results are stored in :term:`$LOG_DIR <LOG_DIR>` (e.g.
+"-c" option and task name:
+::
+
+   $ bitbake core-image-minimal -c checkpkg
+
+By default, the results are stored in :term:`$LOG_DIR <LOG_DIR>` (e.g.
 ``$BUILD_DIR/tmp/log``).
 
 .. _ref-tasks-checkuri:
@@ -473,11 +493,13 @@ Removes all output files for a target from the
 :ref:`ref-tasks-install`, and
 :ref:`ref-tasks-package`).
 
-You can run this task using BitBake as follows: $ bitbake -c clean
-recipe
+You can run this task using BitBake as follows:
+::
+
+   $ bitbake -c clean recipe
 
 Running this task does not remove the
-`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__ cache files.
+:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>` cache files.
 Consequently, if no changes have been made and the recipe is rebuilt
 after cleaning, output files are simply restored from the sstate cache.
 If you want to remove the sstate cache files for the recipe, you need to
@@ -490,14 +512,16 @@ use the :ref:`ref-tasks-cleansstate` task instead
 ---------------
 
 Removes all output files, shared state
-(`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache, and
+(:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache, and
 downloaded source files for a target (i.e. the contents of
 :term:`DL_DIR`). Essentially, the ``do_cleanall`` task is
 identical to the :ref:`ref-tasks-cleansstate` task
 with the added removal of downloaded source files.
 
-You can run this task using BitBake as follows: $ bitbake -c cleanall
-recipe
+You can run this task using BitBake as follows:
+::
+
+   $ bitbake -c cleanall recipe
 
 Typically, you would not normally use the ``cleanall`` task. Do so only
 if you want to start fresh with the :ref:`ref-tasks-fetch`
@@ -509,14 +533,16 @@ task.
 ------------------
 
 Removes all output files and shared state
-(`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache for a
+(:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache for a
 target. Essentially, the ``do_cleansstate`` task is identical to the
 :ref:`ref-tasks-clean` task with the added removal of
-shared state (`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__)
+shared state (`:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`)
 cache.
 
-You can run this task using BitBake as follows: $ bitbake -c cleansstate
-recipe
+You can run this task using BitBake as follows:
+::
+
+   $ bitbake -c cleansstate recipe
 
 When you run the ``do_cleansstate`` task, the OpenEmbedded build system
 no longer uses any sstate. Consequently, building the recipe from
@@ -531,8 +557,8 @@ scratch is guaranteed.
    as follows:
    ::
 
-           $ bitbake -f -c do_cleansstate target
-                      
+      $ bitbake -f -c do_cleansstate target
+
 
 .. _ref-tasks-devpyshell:
 
@@ -542,9 +568,7 @@ scratch is guaranteed.
 Starts a shell in which an interactive Python interpreter allows you to
 interact with the BitBake build environment. From within this shell, you
 can directly examine and set bits from the data store and execute
-functions as if within the BitBake environment. See the "`Using a
-Development Python
-Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devpyshell>`__" section in
+functions as if within the BitBake environment. See the ":ref:`platdev-appdev-devpyshell`" section in
 the Yocto Project Development Tasks Manual for more information about
 using ``devpyshell``.
 
@@ -554,8 +578,7 @@ using ``devpyshell``.
 ---------------
 
 Starts a shell whose environment is set up for development, debugging,
-or both. See the "`Using a Development
-Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell>`__" section in the
+or both. See the ":ref:`platdev-appdev-devshell`" section in the
 Yocto Project Development Tasks Manual for more information about using
 ``devshell``.
 
@@ -571,8 +594,7 @@ Lists all defined tasks for a target.
 ``do_package_index``
 --------------------
 
-Creates or updates the index in the `Package
-Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__ area.
+Creates or updates the index in the `:ref:`package-feeds-dev-environment` area.
 
 .. note::
 
@@ -615,8 +637,7 @@ has some more information about these types of images.
 -------------
 
 Creates the root filesystem (file and directory structure) for an image.
-See the "`Image
-Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__"
+See the ":ref:`image-generation-dev-environment`"
 section in the Yocto Project Overview and Concepts Manual for more
 information on how the root filesystem is created.
 
@@ -626,9 +647,8 @@ information on how the root filesystem is created.
 ----------------
 
 Boots an image and performs runtime tests within the image. For
-information on automatically testing images, see the "`Performing
-Automated Runtime
-Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+information on automatically testing images, see the
+":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-tasks-testimage_auto:
@@ -640,9 +660,8 @@ Boots an image and performs runtime tests within the image immediately
 after it has been built. This task is enabled when you set
 :term:`TESTIMAGE_AUTO` equal to "1".
 
-For information on automatically testing images, see the "`Performing
-Automated Runtime
-Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+For information on automatically testing images, see the
+":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 Kernel-Related Tasks
@@ -674,9 +693,13 @@ changes made by the user with other methods (i.e. using
 (:ref:`ref-tasks-kernel_menuconfig`). Once the
 file of differences is created, it can be used to create a config
 fragment that only contains the differences. You can invoke this task
-from the command line as follows: $ bitbake linux-yocto -c diffconfig
-For more information, see the "`Creating Configuration
-Fragments <&YOCTO_DOCS_KERNEL_DEV_URL;#creating-config-fragments>`__"
+from the command line as follows:
+::
+
+   $ bitbake linux-yocto -c diffconfig
+
+For more information, see the
+":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
 section in the Yocto Project Linux Kernel Development Manual.
 
 .. _ref-tasks-kernel_checkout:
@@ -701,9 +724,13 @@ Validates the configuration produced by the
 configuration does not appear in the final ``.config`` file or when you
 override a policy configuration in a hardware configuration fragment.
 You can run this task explicitly and view the output by using the
-following command: $ bitbake linux-yocto -c kernel_configcheck -f For
-more information, see the "`Validating
-Configuration <&YOCTO_DOCS_KERNEL_DEV_URL;#validating-configuration>`__"
+following command:
+::
+
+   $ bitbake linux-yocto -c kernel_configcheck -f
+
+For more information, see the
+":ref:`kernel-dev/kernel-dev-common:validating configuration`"
 section in the Yocto Project Linux Kernel Development Manual.
 
 .. _ref-tasks-kernel_configme:
@@ -733,10 +760,9 @@ tool, which you then use to modify the kernel configuration.
    ::
 
            $ bitbake linux-yocto -c menuconfig
-                      
 
-See the "`Using
-``menuconfig`` <&YOCTO_DOCS_KERNEL_DEV_URL;#using-menuconfig>`__"
+
+See the ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
 section in the Yocto Project Linux Kernel Development Manual for more
 information on this configuration tool.
 
@@ -760,7 +786,7 @@ which can then be applied by subsequent tasks such as
 
 Runs ``make menuconfig`` for the kernel. For information on
 ``menuconfig``, see the
-"`Using  ``menuconfig`` <&YOCTO_DOCS_KERNEL_DEV_URL;#using-menuconfig>`__"
+":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
 section in the Yocto Project Linux Kernel Development Manual.
 
 .. _ref-tasks-savedefconfig:
@@ -773,8 +799,10 @@ instead of the default defconfig. The saved defconfig contains the
 differences between the default defconfig and the changes made by the
 user using other methods (i.e. the
 :ref:`ref-tasks-kernel_menuconfig` task. You
-can invoke the task using the following command: $ bitbake linux-yocto
--c savedefconfig
+can invoke the task using the following command:
+::
+
+   $ bitbake linux-yocto -c savedefconfig
 
 .. _ref-tasks-shared_workdir:
 
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index 24eff62bcd..312fc12ef0 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -26,7 +26,12 @@ universal, the list includes them just in case:
 
       When you name an append file, you can use the "``%``" wildcard character
       to allow for matching recipe names. For example, suppose you have an
-      append file named as follows: busybox_1.21.%.bbappend That append file
+      append file named as follows:
+      ::
+      
+         busybox_1.21.%.bbappend
+
+      That append file
       would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So,
       the append file would match any of the following recipe names:
 
@@ -68,11 +73,11 @@ universal, the list includes them just in case:
       examples assume your :term:`Source Directory` is named ``poky``:
 
          -  Create the Build Directory inside your Source Directory and let
-            the name of the Build Directory default to ``build``: 
+            the name of the Build Directory default to ``build``:
 
             .. code-block:: shell
 
-               $ cd $HOME/poky 
+               $ cd $HOME/poky
                $ source oe-init-build-env
 
          -  Create the Build Directory inside your home directory and
@@ -80,18 +85,18 @@ universal, the list includes them just in case:
 
             .. code-block:: shell
 
-               $ cd $HOME 
+               $ cd $HOME
                $ source poky/oe-init-build-env test-builds
 
          -  Provide a directory path and specifically name the Build
             Directory. Any intermediate folders in the pathname must exist.
             This next example creates a Build Directory named
             ``YP-POKYVERSION`` in your home directory within the existing
-            directory ``mybuilds``: 
+            directory ``mybuilds``:
 
             .. code-block:: shell
 
-               $ cd $HOME 
+               $ cd $HOME
                $ source $HOME/poky/oe-init-build-env $HOME/mybuilds/YP-POKYVERSION
 
       .. note::
@@ -349,8 +354,9 @@ universal, the list includes them just in case:
      While it is not recommended that you use tarball expansion to set up
      the Source Directory, if you do, the top-level directory name of the
      Source Directory is derived from the Yocto Project release tarball.
-     For example, downloading and unpacking ```` results in a Source
-     Directory whose root folder is named ````.
+     For example, downloading and unpacking
+     :yocto_dl:`releases/yocto/&DISTRO_REL_TAG;/&YOCTO_POKY;.tar.bz2`
+     results in a Source Directory whose root folder is named ``poky``.
 
      It is important to understand the differences between the Source
      Directory created by unpacking a released tarball as compared to
@@ -366,8 +372,8 @@ universal, the list includes them just in case:
      repository.
 
      For more information on concepts related to Git repositories,
-     branches, and tags, see the "`Repositories, Tags, and
-     Branches <&YOCTO_DOCS_OM_URL;#repositories-tags-and-branches>`__"
+     branches, and tags, see the
+     ":ref:`overview-manual/overview-manual-development-environment:repositories, tags, and branches`"
      section in the Yocto Project Overview and Concepts Manual.
 
    Task
@@ -381,7 +387,7 @@ universal, the list includes them just in case:
       The interface enables you to
       configure and run your builds. Information about builds is collected
       and stored in a database. For information on Toaster, see the
-      `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__.
+      :doc:`../toaster-manual/toaster-manual`.
 
    Upstream
       A reference to source code or repositories that are not
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index 54a892576b..625a37c158 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -21,74 +21,86 @@ system and gives an overview of their function and contents.
    ABIEXTENSION
       Extension to the Application Binary Interface (ABI) field of the GNU
       canonical architecture name (e.g. "eabi").
-   
+
       ABI extensions are set in the machine include files. For example, the
       ``meta/conf/machine/include/arm/arch-arm.inc`` file sets the
-      following extension: ABIEXTENSION = "eabi"
-   
+      following extension:
+      ::
+
+         ABIEXTENSION = "eabi"
+
    ALLOW_EMPTY
       Specifies whether to produce an output package even if it is empty.
       By default, BitBake does not produce empty packages. This default
       behavior can cause issues when there is an
       :term:`RDEPENDS` or some other hard runtime
       requirement on the existence of the package.
-   
+
       Like all package-controlling variables, you must always use them in
-      conjunction with a package name override, as in: ALLOW_EMPTY_${PN} =
-      "1" ALLOW_EMPTY_${PN}-dev = "1" ALLOW_EMPTY_${PN}-staticdev = "1"
-   
+      conjunction with a package name override, as in:
+      ::
+
+         ALLOW_EMPTY_${PN} = "1"
+         ALLOW_EMPTY_${PN}-dev = "1"
+         ALLOW_EMPTY_${PN}-staticdev = "1"
+
    ALTERNATIVE
       Lists commands in a package that need an alternative binary naming
       scheme. Sometimes the same command is provided in multiple packages.
       When this occurs, the OpenEmbedded build system needs to use the
       alternatives system to create a different binary naming scheme so the
       commands can co-exist.
-   
+
       To use the variable, list out the package's commands that also exist
       as part of another package. For example, if the ``busybox`` package
       has four commands that also exist as part of another package, you
-      identify them as follows: ALTERNATIVE_busybox = "sh sed test bracket"
+      identify them as follows:
+      ::
+
+         ALTERNATIVE_busybox = "sh sed test bracket"
+
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
-   
+
    ALTERNATIVE_LINK_NAME
       Used by the alternatives system to map duplicated commands to actual
       locations. For example, if the ``bracket`` command provided by the
       ``busybox`` package is duplicated through another package, you must
       use the ``ALTERNATIVE_LINK_NAME`` variable to specify the actual
-      location: ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
-   
+      location:
+      ::
+
+         ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
+
       In this example, the binary for the ``bracket`` command (i.e. ``[``)
       from the ``busybox`` package resides in ``/usr/bin/``.
-   
+
       .. note::
-   
-         If
-         ALTERNATIVE_LINK_NAME
-         is not defined, it defaults to
-         ${bindir}/
-         name
-         .
-   
+
+         If ALTERNATIVE_LINK_NAME is not defined, it defaults to ${bindir}/ name.
+
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
-   
+
    ALTERNATIVE_PRIORITY
       Used by the alternatives system to create default priorities for
       duplicated commands. You can use the variable to create a single
       default regardless of the command name or package, a default for
       specific duplicated commands regardless of the package, or a default
       for specific commands tied to particular packages. Here are the
-      available syntax forms: ALTERNATIVE_PRIORITY = "priority"
-      ALTERNATIVE_PRIORITY[name] = "priority"
-      ALTERNATIVE_PRIORITY_pkg[name] = "priority"
-   
+      available syntax forms:
+      ::
+
+         ALTERNATIVE_PRIORITY = "priority"
+         ALTERNATIVE_PRIORITY[name] = "priority"
+         ALTERNATIVE_PRIORITY_pkg[name] = "priority"
+
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
-   
+
    ALTERNATIVE_TARGET
       Used by the alternatives system to create default link locations for
       duplicated commands. You can use the variable to create a single
@@ -96,105 +108,115 @@ system and gives an overview of their function and contents.
       command name or package, a default for specific duplicated commands
       regardless of the package, or a default for specific commands tied to
       particular packages. Here are the available syntax forms:
-      ALTERNATIVE_TARGET = "target" ALTERNATIVE_TARGET[name] = "target"
-      ALTERNATIVE_TARGET_pkg[name] = "target"
-   
+      ::
+
+         ALTERNATIVE_TARGET = "target"
+         ALTERNATIVE_TARGET[name] = "target"
+         ALTERNATIVE_TARGET_pkg[name] = "target"
+
       .. note::
-   
+
          If ``ALTERNATIVE_TARGET`` is not defined, it inherits the value
-         from the
-         :term:`ALTERNATIVE_LINK_NAME`
-         variable.
-   
+         from the :term:`ALTERNATIVE_LINK_NAME` variable.
+
          If ``ALTERNATIVE_LINK_NAME`` and ``ALTERNATIVE_TARGET`` are the
          same, the target for ``ALTERNATIVE_TARGET`` has "``.{BPN}``"
          appended to it.
-   
+
          Finally, if the file referenced has not been renamed, the
          alternatives system will rename it to avoid the need to rename
          alternative files in the :ref:`ref-tasks-install`
          task while retaining support for the command if necessary.
-   
+
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
-   
+
    APPEND
       An override list of append strings for each target specified with
       :term:`LABELS`.
-   
+
       See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
       information on how this variable is used.
-   
+
    AR
       The minimal command and arguments used to run ``ar``.
-   
+
    ARCHIVER_MODE
       When used with the :ref:`archiver <ref-classes-archiver>` class,
       determines the type of information used to create a released archive.
       You can use this variable to create archives of patched source,
       original source, configured source, and so forth by employing the
-      following variable flags (varflags): ARCHIVER_MODE[src] = "original"
-      # Uses original (unpacked) source # files. ARCHIVER_MODE[src] =
-      "patched" # Uses patched source files. This is # the default.
-      ARCHIVER_MODE[src] = "configured" # Uses configured source files.
-      ARCHIVER_MODE[diff] = "1" # Uses patches between do_unpack and #
-      do_patch. ARCHIVER_MODE[diff-exclude] ?= "file file ..." # Lists
-      files and directories to # exclude from diff. ARCHIVER_MODE[dumpdata]
-      = "1" # Uses environment data. ARCHIVER_MODE[recipe] = "1" # Uses
-      recipe and include files. ARCHIVER_MODE[srpm] = "1" # Uses RPM
-      package files. For information on how the variable works, see the
+      following variable flags (varflags):
+      ::
+
+         ARCHIVER_MODE[src] = "original"                   # Uses original (unpacked) source files.
+         ARCHIVER_MODE[src] = "patched"                    # Uses patched source files. This is the default.
+         ARCHIVER_MODE[src] = "configured"                 # Uses configured source files.
+         ARCHIVER_MODE[diff] = "1"                         # Uses patches between do_unpack and do_patch.
+         ARCHIVER_MODE[diff-exclude] ?= "file file ..."    # Lists files and directories to exclude from diff.
+         ARCHIVER_MODE[dumpdata] = "1"                     # Uses environment data.
+         ARCHIVER_MODE[recipe] = "1"                       # Uses recipe and include files.
+         ARCHIVER_MODE[srpm] = "1"                         # Uses RPM package files.
+
+      For information on how the variable works, see the
       ``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`.
-   
+
    AS
       Minimal command and arguments needed to run the assembler.
-   
+
    ASSUME_PROVIDED
       Lists recipe names (:term:`PN` values) BitBake does not
       attempt to build. Instead, BitBake assumes these recipes have already
       been built.
-   
+
       In OpenEmbedded-Core, ``ASSUME_PROVIDED`` mostly specifies native
       tools that should not be built. An example is ``git-native``, which
       when specified, allows for the Git binary from the host to be used
       rather than building ``git-native``.
-   
+
    ASSUME_SHLIBS
       Provides additional ``shlibs`` provider mapping information, which
       adds to or overwrites the information provided automatically by the
       system. Separate multiple entries using spaces.
-   
+
       As an example, use the following form to add an ``shlib`` provider of
       shlibname in packagename with the optional version:
-      shlibname:packagename[_version]
-   
+      ::
+
+         shlibname:packagename[_version]
+
       Here is an example that adds a shared library named ``libEGL.so.1``
       as being provided by the ``libegl-implementation`` package:
-      ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"
-   
+      ::
+
+         ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"
+
    AUTHOR
       The email address used to contact the original author or authors in
       order to send patches and forward bugs.
-   
+
    AUTO_LIBNAME_PKGS
       When the :ref:`debian <ref-classes-debian>` class is inherited,
       which is the default behavior, ``AUTO_LIBNAME_PKGS`` specifies which
       packages should be checked for libraries and renamed according to
       Debian library package naming.
-   
+
       The default value is "${PACKAGES}", which causes the debian class to
       act on all packages that are explicitly generated by the recipe.
-   
+
    AUTO_SYSLINUXMENU
       Enables creating an automatic menu for the syslinux bootloader. You
       must set this variable in your recipe. The
       :ref:`syslinux <ref-classes-syslinux>` class checks this variable.
-   
+
    AUTOREV
       When ``SRCREV`` is set to the value of this variable, it specifies to
       use the latest source revision in the repository. Here is an example:
-      SRCREV = "${AUTOREV}"
-   
+      ::
+
+         SRCREV = "${AUTOREV}"
+
       If you use the previous statement to retrieve the latest version of
       software, you need to be sure :term:`PV` contains
       ``${``\ :term:`SRCPV`\ ``}``. For example, suppose you
@@ -203,19 +225,18 @@ system and gives an overview of their function and contents.
       statement. In this example, ``${SRCPV}`` does not automatically get
       into ``PV``. Consequently, you need to change ``PV`` in your recipe
       so that it does contain ``${SRCPV}``.
-   
-      For more information see the "`Automatically Incrementing a Binary
-      Package Revision
-      Number <&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number>`__"
+
+      For more information see the
+      ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    AVAILABLE_LICENSES
       List of licenses found in the directories specified by
       :term:`COMMON_LICENSE_DIR` and
       :term:`LICENSE_PATH`.
-   
+
       .. note::
-   
+
          It is assumed that all changes to
          COMMON_LICENSE_DIR
          and
@@ -225,106 +246,113 @@ system and gives an overview of their function and contents.
          is defined (in
          license.bbclass
          ).
-   
+
    AVAILTUNES
       The list of defined CPU and Application Binary Interface (ABI)
       tunings (i.e. "tunes") available for use by the OpenEmbedded build
       system.
-   
+
       The list simply presents the tunes that are available. Not all tunes
       may be compatible with a particular machine configuration, or with
       each other in a
-      `Multilib <&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image>`__
+      :ref:`Multilib <dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image>`
       configuration.
-   
+
       To add a tune to the list, be sure to append it with spaces using the
       "+=" BitBake operator. Do not simply replace the list by using the
       "=" operator. See the
       ":ref:`Basic Syntax <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:basic syntax>`" section in the BitBake
       User Manual for more information.
-   
+
    B
       The directory within the :term:`Build Directory` in
       which the OpenEmbedded build system places generated objects during a
       recipe's build process. By default, this directory is the same as the
-      :term:`S` directory, which is defined as: S =
-      "${WORKDIR}/${BP}"
-   
+      :term:`S` directory, which is defined as:
+      ::
+
+         S = "${WORKDIR}/${BP}"
+
       You can separate the (``S``) directory and the directory pointed to
       by the ``B`` variable. Most Autotools-based recipes support
       separating these directories. The build system defaults to using
       separate directories for ``gcc`` and some kernel recipes.
-   
+
    BAD_RECOMMENDATIONS
       Lists "recommended-only" packages to not install. Recommended-only
       packages are packages installed only through the
       :term:`RRECOMMENDS` variable. You can prevent any
       of these "recommended" packages from being installed by listing them
-      with the ``BAD_RECOMMENDATIONS`` variable: BAD_RECOMMENDATIONS =
-      "package_name package_name package_name ..."
-   
+      with the ``BAD_RECOMMENDATIONS`` variable:
+      ::
+
+         BAD_RECOMMENDATIONS = "package_name package_name package_name ..."
+
       You can set this variable globally in your ``local.conf`` file or you
       can attach it to a specific image recipe by using the recipe name
-      override: BAD_RECOMMENDATIONS_pn-target_image = "package_name"
-   
+      override:
+      ::
+
+         BAD_RECOMMENDATIONS_pn-target_image = "package_name"
+
       It is important to realize that if you choose to not install packages
       using this variable and some other packages are dependent on them
       (i.e. listed in a recipe's :term:`RDEPENDS`
       variable), the OpenEmbedded build system ignores your request and
       will install the packages to avoid dependency errors.
-   
+
       Support for this variable exists only when using the IPK and RPM
       packaging backend. Support does not exist for DEB.
-   
+
       See the :term:`NO_RECOMMENDATIONS` and the
       :term:`PACKAGE_EXCLUDE` variables for related
       information.
-   
+
    BASE_LIB
       The library directory name for the CPU or Application Binary
       Interface (ABI) tune. The ``BASE_LIB`` applies only in the Multilib
-      context. See the "`Combining Multiple Versions of Library Files into
-      One
-      Image <&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image>`__"
+      context. See the ":ref:`dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image`"
       section in the Yocto Project Development Tasks Manual for information
       on Multilib.
-   
+
       The ``BASE_LIB`` variable is defined in the machine include files in
       the :term:`Source Directory`. If Multilib is not
       being used, the value defaults to "lib".
-   
+
    BASE_WORKDIR
       Points to the base of the work directory for all recipes. The default
       value is "${TMPDIR}/work".
-   
+
    BB_ALLOWED_NETWORKS
       Specifies a space-delimited list of hosts that the fetcher is allowed
       to use to obtain the required source code. Following are
       considerations surrounding this variable:
-   
+
       -  This host list is only used if ``BB_NO_NETWORK`` is either not set
          or set to "0".
-   
+
       -  Limited support for wildcard matching against the beginning of
          host names exists. For example, the following setting matches
          ``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``.
-         BB_ALLOWED_NETWORKS = "*.gnu.org"
-   
+         ::
+
+            BB_ALLOWED_NETWORKS = "*.gnu.org"
+
          .. note::
-   
+
             The use of the "``*``" character only works at the beginning of
             a host name and it must be isolated from the remainder of the
             host name. You cannot use the wildcard character in any other
             location of the name or combined with the front part of the
             name.
-   
+
             For example, ``*.foo.bar`` is supported, while ``*aa.foo.bar``
             is not.
-   
+
       -  Mirrors not in the host list are skipped and logged in debug.
-   
+
       -  Attempts to access networks not in the host list cause a failure.
-   
+
       Using ``BB_ALLOWED_NETWORKS`` in conjunction with
       :term:`PREMIRRORS` is very useful. Adding the host
       you want to use to ``PREMIRRORS`` results in the source code being
@@ -333,7 +361,7 @@ system and gives an overview of their function and contents.
       statement. This is because the fetcher does not attempt to use the
       host listed in ``SRC_URI`` after a successful fetch from the
       ``PREMIRRORS`` occurs.
-   
+
    BB_DANGLINGAPPENDS_WARNONLY
       Defines how BitBake handles situations where an append file
       (``.bbappend``) has no corresponding recipe file (``.bb``). This
@@ -341,42 +369,69 @@ system and gives an overview of their function and contents.
       bumps a recipe version and the old recipe no longer exists and the
       other layer has not been updated to the new version of the recipe
       yet).
-   
+
       The default fatal behavior is safest because it is the sane reaction
       given something is out of sync. It is important to realize when your
       changes are no longer being applied.
-   
+
       You can change the default behavior by setting this variable to "1",
       "yes", or "true" in your ``local.conf`` file, which is located in the
       :term:`Build Directory`: Here is an example:
-      BB_DANGLINGAPPENDS_WARNONLY = "1"
-   
+      ::
+
+         BB_DANGLINGAPPENDS_WARNONLY = "1"
+
    BB_DISKMON_DIRS
       Monitors disk space and available inodes during the build and allows
       you to control the build based on these parameters.
-   
+
       Disk space monitoring is disabled by default. To enable monitoring,
       add the ``BB_DISKMON_DIRS`` variable to your ``conf/local.conf`` file
       found in the :term:`Build Directory`. Use the
-      following form: BB_DISKMON_DIRS = "action,dir,threshold [...]" where:
-      action is: ABORT: Immediately abort the build when a threshold is
-      broken. STOPTASKS: Stop the build after the currently executing tasks
-      have finished when a threshold is broken. WARN: Issue a warning but
-      continue the build when a threshold is broken. Subsequent warnings
-      are issued as defined by the BB_DISKMON_WARNINTERVAL variable, which
-      must be defined in the conf/local.conf file. dir is: Any directory
-      you choose. You can specify one or more directories to monitor by
-      separating the groupings with a space. If two directories are on the
-      same device, only the first directory is monitored. threshold is:
-      Either the minimum available disk space, the minimum number of free
-      inodes, or both. You must specify at least one. To omit one or the
-      other, simply omit the value. Specify the threshold using G, M, K for
-      Gbytes, Mbytes, and Kbytes, respectively. If you do not specify G, M,
-      or K, Kbytes is assumed by default. Do not use GB, MB, or KB.
-   
-      Here are some examples: BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K
-      WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_DIRS =
-      "STOPTASKS,${TMPDIR},1G" BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
+      following form:
+      ::
+
+         BB_DISKMON_DIRS = "action,dir,threshold [...]"
+
+         where:
+
+            action is:
+               ABORT:     Immediately abort the build when
+                          a threshold is broken.
+               STOPTASKS: Stop the build after the currently
+                          executing tasks have finished when
+                          a threshold is broken.
+               WARN:      Issue a warning but continue the
+                          build when a threshold is broken.
+                          Subsequent warnings are issued as
+                          defined by the BB_DISKMON_WARNINTERVAL
+                          variable, which must be defined in
+                          the conf/local.conf file.
+
+            dir is:
+               Any directory you choose. You can specify one or
+               more directories to monitor by separating the
+               groupings with a space.  If two directories are
+               on the same device, only the first directory
+               is monitored.
+
+            threshold is:
+               Either the minimum available disk space,
+               the minimum number of free inodes, or
+               both.  You must specify at least one.  To
+               omit one or the other, simply omit the value.
+               Specify the threshold using G, M, K for Gbytes,
+               Mbytes, and Kbytes, respectively. If you do
+               not specify G, M, or K, Kbytes is assumed by
+               default.  Do not use GB, MB, or KB.
+
+      Here are some examples:
+      ::
+
+         BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
+         BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
+         BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
+
       The first example works only if you also provide the
       :term:`BB_DISKMON_WARNINTERVAL`
       variable in the ``conf/local.conf``. This example causes the build
@@ -388,64 +443,85 @@ system and gives an overview of their function and contents.
       of free inodes drops below 100 Kbytes. Subsequent warnings are issued
       during intervals as defined by the ``BB_DISKMON_WARNINTERVAL``
       variable.
-   
+
       The second example stops the build after all currently executing
       tasks complete when the minimum disk space in the ``${TMPDIR}``
       directory drops below 1 Gbyte. No disk monitoring occurs for the free
       inodes in this case.
-   
+
       The final example immediately aborts the build when the number of
       free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No
       disk space monitoring for the directory itself occurs in this case.
-   
+
    BB_DISKMON_WARNINTERVAL
       Defines the disk space and free inode warning intervals. To set these
       intervals, define the variable in your ``conf/local.conf`` file in
       the :term:`Build Directory`.
-   
+
       If you are going to use the ``BB_DISKMON_WARNINTERVAL`` variable, you
       must also use the :term:`BB_DISKMON_DIRS`
       variable and define its action as "WARN". During the build,
       subsequent warnings are issued each time disk space or number of free
       inodes further reduces by the respective interval.
-   
+
       If you do not provide a ``BB_DISKMON_WARNINTERVAL`` variable and you
       do use ``BB_DISKMON_DIRS`` with the "WARN" action, the disk
       monitoring interval defaults to the following:
-      BB_DISKMON_WARNINTERVAL = "50M,5K"
-   
+      ::
+
+         BB_DISKMON_WARNINTERVAL = "50M,5K"
+
       When specifying the variable in your configuration file, use the
-      following form: BB_DISKMON_WARNINTERVAL =
-      "disk_space_interval,disk_inode_interval" where: disk_space_interval
-      is: An interval of memory expressed in either G, M, or K for Gbytes,
-      Mbytes, or Kbytes, respectively. You cannot use GB, MB, or KB.
-      disk_inode_interval is: An interval of free inodes expressed in
-      either G, M, or K for Gbytes, Mbytes, or Kbytes, respectively. You
-      cannot use GB, MB, or KB.
-   
-      Here is an example: BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
-      BB_DISKMON_WARNINTERVAL = "50M,5K" These variables cause the
+      following form:
+      ::
+
+         BB_DISKMON_WARNINTERVAL = "disk_space_interval,disk_inode_interval"
+
+         where:
+
+            disk_space_interval is:
+               An interval of memory expressed in either
+               G, M, or K for Gbytes, Mbytes, or Kbytes,
+               respectively. You cannot use GB, MB, or KB.
+
+            disk_inode_interval is:
+               An interval of free inodes expressed in either
+               G, M, or K for Gbytes, Mbytes, or Kbytes,
+               respectively. You cannot use GB, MB, or KB.
+
+      Here is an example:
+      ::
+
+         BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
+         BB_DISKMON_WARNINTERVAL = "50M,5K"
+
+      These variables cause the
       OpenEmbedded build system to issue subsequent warnings each time the
       available disk space further reduces by 50 Mbytes or the number of
       free inodes further reduces by 5 Kbytes in the ``${SSTATE_DIR}``
       directory. Subsequent warnings based on the interval occur each time
       a respective interval is reached beyond the initial warning (i.e. 1
       Gbytes and 100 Kbytes).
-   
+
    BB_GENERATE_MIRROR_TARBALLS
       Causes tarballs of the source control repositories (e.g. Git
       repositories), including metadata, to be placed in the
       :term:`DL_DIR` directory.
-   
+
       For performance reasons, creating and placing tarballs of these
       repositories is not the default action by the OpenEmbedded build
-      system. BB_GENERATE_MIRROR_TARBALLS = "1" Set this variable in your
+      system.
+      ::
+
+         BB_GENERATE_MIRROR_TARBALLS = "1"
+
+      Set this variable in your
       ``local.conf`` file in the :term:`Build Directory`.
-   
+
       Once you have the tarballs containing your source files, you can
       clean up your ``DL_DIR`` directory by deleting any Git or other
       source control work directories.
-   
+
    BB_NUMBER_THREADS
       The maximum number of tasks BitBake should run in parallel at any one
       time. The OpenEmbedded build system automatically configures this
@@ -453,27 +529,31 @@ system and gives an overview of their function and contents.
       example, a system with a dual core processor that also uses
       hyper-threading causes the ``BB_NUMBER_THREADS`` variable to default
       to "4".
-   
+
       For single socket systems (i.e. one CPU), you should not have to
       override this variable to gain optimal parallelism during builds.
       However, if you have very large systems that employ multiple physical
       CPUs, you might want to make sure the ``BB_NUMBER_THREADS`` variable
       is not set higher than "20".
-   
-      For more information on speeding up builds, see the "`Speeding Up a
-      Build <&YOCTO_DOCS_DEV_URL;#speeding-up-a-build>`__" section in the
-      Yocto Project Development Tasks Manual.
-   
+
+      For more information on speeding up builds, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+      section in the Yocto Project Development Tasks Manual.
+
    BB_SERVER_TIMEOUT
       Specifies the time (in seconds) after which to unload the BitBake
       server due to inactivity. Set ``BB_SERVER_TIMEOUT`` to determine how
       long the BitBake server stays resident between invocations.
-   
+
       For example, the following statement in your ``local.conf`` file
       instructs the server to be unloaded after 20 seconds of inactivity:
-      BB_SERVER_TIMEOUT = "20" If you want the server to never be unloaded,
+      ::
+
+         BB_SERVER_TIMEOUT = "20"
+
+      If you want the server to never be unloaded,
       set ``BB_SERVER_TIMEOUT`` to "-1".
-   
+
    BBCLASSEXTEND
       Allows you to extend a recipe so that it builds variants of the
       software. Common variants for recipes exist such as "natives" like
@@ -483,40 +563,42 @@ system and gives an overview of their function and contents.
       :term:`MACHINE`; "nativesdk", which targets the SDK
       machine instead of ``MACHINE``; and "mulitlibs" in the form
       "``multilib:``\ multilib_name".
-   
+
       To build a different variant of the recipe with a minimal amount of
       code, it usually is as simple as adding the following to your recipe:
-      BBCLASSEXTEND =+ "native nativesdk" BBCLASSEXTEND =+
-      "multilib:multilib_name"
-   
+      ::
+
+         BBCLASSEXTEND =+ "native nativesdk"
+         BBCLASSEXTEND =+ "multilib:multilib_name"
+
       .. note::
-   
+
          Internally, the ``BBCLASSEXTEND`` mechanism generates recipe
          variants by rewriting variable values and applying overrides such
          as ``_class-native``. For example, to generate a native version of
          a recipe, a :term:`DEPENDS` on "foo" is rewritten
          to a ``DEPENDS`` on "foo-native".
-   
+
          Even when using ``BBCLASSEXTEND``, the recipe is only parsed once.
          Parsing once adds some limitations. For example, it is not
          possible to include a different file depending on the variant,
          since ``include`` statements are processed when the recipe is
          parsed.
-   
+
    BBFILE_COLLECTIONS
       Lists the names of configured layers. These names are used to find
       the other ``BBFILE_*`` variables. Typically, each layer will append
       its name to this variable in its ``conf/layer.conf`` file.
-   
+
    BBFILE_PATTERN
       Variable that expands to match files from
       :term:`BBFILES` in a particular layer. This variable
       is used in the ``conf/layer.conf`` file and must be suffixed with the
       name of the specific layer (e.g. ``BBFILE_PATTERN_emenlow``).
-   
+
    BBFILE_PRIORITY
       Assigns the priority for recipe files in each layer.
-   
+
       This variable is useful in situations where the same recipe appears
       in more than one layer. Setting this variable allows you to
       prioritize a layer against other layers that contain the same recipe
@@ -526,7 +608,7 @@ system and gives an overview of their function and contents.
       example, a layer that has a recipe with a higher ``PV`` value but for
       which the ``BBFILE_PRIORITY`` is set to have a lower precedence still
       has a lower precedence.
-   
+
       A larger value for the ``BBFILE_PRIORITY`` variable results in a
       higher precedence. For example, the value 6 has a higher precedence
       than the value 5. If not specified, the ``BBFILE_PRIORITY`` variable
@@ -534,116 +616,136 @@ system and gives an overview of their function and contents.
       for more information. The default priority, if unspecified for a
       layer with no dependencies, is the lowest defined priority + 1 (or 1
       if no priorities are defined).
-   
+
       .. tip::
-   
+
          You can use the command
          bitbake-layers show-layers
          to list all configured layers along with their priorities.
-   
+
    BBFILES
       A space-separated list of recipe files BitBake uses to build
       software.
-   
+
       When specifying recipe files, you can pattern match using Python's
-      ```glob`https://docs.python.org/3/library/glob.html syntax.
+      `glob <https://docs.python.org/3/library/glob.html>`_ syntax.
       For details on the syntax, see the documentation by following the
       previous link.
-   
+
    BBFILES_DYNAMIC
       Activates content when identified layers are present. You identify
       the layers by the collections that the layers define.
-   
+
       Use the ``BBFILES_DYNAMIC`` variable to avoid ``.bbappend`` files
       whose corresponding ``.bb`` file is in a layer that attempts to
       modify other layers through ``.bbappend`` but does not want to
       introduce a hard dependency on those other layers.
-   
+
       Use the following form for ``BBFILES_DYNAMIC``:
       collection_name:filename_pattern The following example identifies two
-      collection names and two filename patterns: BBFILES_DYNAMIC += " \\
-      clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \\
-      core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \\ "
+      collection names and two filename patterns:
+      ::
+
+         BBFILES_DYNAMIC += " \
+            clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
+            core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
+            "
+
       This next example shows an error message that occurs because invalid
-      entries are found, which cause parsing to abort: ERROR:
-      BBFILES_DYNAMIC entries must be of the form <collection
-      name>:<filename pattern>, not:
-      /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
-      /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
-   
+      entries are found, which cause parsing to abort:
+      ::
+
+         ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
+             /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
+             /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
+
    BBINCLUDELOGS
       Variable that controls how BitBake displays logs on build failure.
-   
+
    BBINCLUDELOGS_LINES
       If :term:`BBINCLUDELOGS` is set, specifies the
       maximum number of lines from the task log file to print when
       reporting a failed task. If you do not set ``BBINCLUDELOGS_LINES``,
       the entire log is printed.
-   
+
    BBLAYERS
       Lists the layers to enable during the build. This variable is defined
       in the ``bblayers.conf`` configuration file in the :term:`Build Directory`.
-      Here is an example: BBLAYERS = " \\
-      /home/scottrif/poky/meta \\ /home/scottrif/poky/meta-poky \\
-      /home/scottrif/poky/meta-yocto-bsp \\
-      /home/scottrif/poky/meta-mykernel \\ "
-   
+      Here is an example:
+      ::
+
+         BBLAYERS = " \
+             /home/scottrif/poky/meta \ /home/scottrif/poky/meta-poky \
+             /home/scottrif/poky/meta-yocto-bsp \
+             /home/scottrif/poky/meta-mykernel \
+             "
+
       This example enables four layers, one of which is a custom,
       user-defined layer named ``meta-mykernel``.
-   
+
    BBMASK
       Prevents BitBake from processing recipes and recipe append files.
-   
+
       You can use the ``BBMASK`` variable to "hide" these ``.bb`` and
       ``.bbappend`` files. BitBake ignores any recipe or recipe append
       files that match any of the expressions. It is as if BitBake does not
       see them at all. Consequently, matching files are not parsed or
       otherwise used by BitBake.
-   
+
       The values you provide are passed to Python's regular expression
       compiler. Consequently, the syntax follows Python's Regular
       Expression (re) syntax. The expressions are compared against the full
       paths to the files. For complete syntax information, see Python's
       documentation at http://docs.python.org/3/library/re.html#re.
-   
+
       The following example uses a complete regular expression to tell
       BitBake to ignore all recipe and recipe append files in the
-      ``meta-ti/recipes-misc/`` directory: BBMASK = "meta-ti/recipes-misc/"
+      ``meta-ti/recipes-misc/`` directory:
+      ::
+
+         BBMASK = "meta-ti/recipes-misc/"
+
       If you want to mask out multiple directories or recipes, you can
       specify multiple regular expression fragments. This next example
-      masks out multiple directories and individual recipes: BBMASK +=
-      "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" BBMASK +=
-      "/meta-oe/recipes-support/" BBMASK += "/meta-foo/.*/openldap" BBMASK
-      += "opencv.*\.bbappend" BBMASK += "lzma"
-   
+      masks out multiple directories and individual recipes: ::
+
+         BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
+         BBMASK += "/meta-oe/recipes-support/"
+         BBMASK += "/meta-foo/.*/openldap"
+         BBMASK += "opencv.*\.bbappend"
+         BBMASK += "lzma"
+
       .. note::
-   
+
          When specifying a directory name, use the trailing slash character
          to ensure you match just that directory name.
-   
+
    BBMULTICONFIG
       Specifies each additional separate configuration when you are
       building targets with multiple configurations. Use this variable in
       your ``conf/local.conf`` configuration file. Specify a
       multiconfigname for each configuration file you are using. For
       example, the following line specifies three configuration files:
-      BBMULTICONFIG = "configA configB configC" Each configuration file you
+      ::
+
+         BBMULTICONFIG = "configA configB configC"
+
+      Each configuration file you
       use must reside in the :term:`Build Directory`
       ``conf/multiconfig`` directory (e.g.
       build_directory\ ``/conf/multiconfig/configA.conf``).
-   
+
       For information on how to use ``BBMULTICONFIG`` in an environment
       that supports building targets with multiple configurations, see the
-      "`Building Images for Multiple Targets Using Multiple
-      Configurations <&YOCTO_DOCS_DEV_URL;#dev-building-images-for-multiple-targets-using-multiple-configurations>`__"
+      ":ref:`dev-building-images-for-multiple-targets-using-multiple-configurations`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    BBPATH
       Used by BitBake to locate ``.bbclass`` and configuration files. This
       variable is analogous to the ``PATH`` variable.
-   
+
       .. note::
-   
+
          If you run BitBake from a directory outside of the
          Build Directory
          , you must be sure to set
@@ -651,24 +753,27 @@ system and gives an overview of their function and contents.
          to point to the Build Directory. Set the variable as you would any
          environment variable and then run BitBake:
          ::
-   
+
                  $ BBPATH = "build_directory"
                  $ export BBPATH
                  $ bitbake target
-                                    
-   
+
+
    BBSERVER
       If defined in the BitBake environment, ``BBSERVER`` points to the
       BitBake remote server.
-   
+
       Use the following format to export the variable to the BitBake
-      environment: export BBSERVER=localhost:$port
-   
+      environment:
+      ::
+
+         export BBSERVER=localhost:$port
+
       By default, ``BBSERVER`` also appears in
       :term:`bitbake:BB_HASHBASE_WHITELIST`.
       Consequently, ``BBSERVER`` is excluded from checksum and dependency
       data.
-   
+
    BINCONFIG
       When inheriting the
       :ref:`binconfig-disabled <ref-classes-binconfig-disabled>` class,
@@ -677,11 +782,13 @@ system and gives an overview of their function and contents.
       ``binconfig-disabled`` class will modify the specified scripts to
       return an error so that calls to them can be easily found and
       replaced.
-   
+
       To add multiple scripts, separate them by spaces. Here is an example
-      from the ``libpng`` recipe: BINCONFIG = "${bindir}/libpng-config
-      ${bindir}/libpng16-config"
-   
+      from the ``libpng`` recipe:
+      ::
+
+         BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config"
+
    BINCONFIG_GLOB
       When inheriting the :ref:`binconfig <ref-classes-binconfig>` class,
       this variable specifies a wildcard for configuration scripts that
@@ -689,9 +796,9 @@ system and gives an overview of their function and contents.
       been set up during compilation so that they are correct for use when
       installed into the sysroot and called by the build processes of other
       recipes.
-   
+
       .. note::
-   
+
          The
          BINCONFIG_GLOB
          variable uses
@@ -702,18 +809,21 @@ system and gives an overview of their function and contents.
          and
          glob
          .
-   
+
       For more information on how this variable works, see
       ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`.
       You can also find general
       information on the class in the
       ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
-   
+
    BP
       The base recipe name and version but without any special recipe name
       suffix (i.e. ``-native``, ``lib64-``, and so forth). ``BP`` is
-      comprised of the following: ${BPN}-${PV}
-   
+      comprised of the following:
+      ::
+
+         ${BPN}-${PV}
+
    BPN
       This variable is a version of the :term:`PN` variable with
       common prefixes and suffixes removed, such as ``nativesdk-``,
@@ -722,115 +832,115 @@ system and gives an overview of their function and contents.
       :term:`MLPREFIX` and
       :term:`SPECIAL_PKGSUFFIX` variables,
       respectively.
-   
+
    BUGTRACKER
       Specifies a URL for an upstream bug tracking website for a recipe.
       The OpenEmbedded build system does not use this variable. Rather, the
       variable is a useful pointer in case a bug in the software being
       built needs to be manually reported.
-   
+
    BUILD_ARCH
       Specifies the architecture of the build host (e.g. ``i686``). The
       OpenEmbedded build system sets the value of ``BUILD_ARCH`` from the
       machine name reported by the ``uname`` command.
-   
+
    BUILD_AS_ARCH
       Specifies the architecture-specific assembler flags for the build
       host. By default, the value of ``BUILD_AS_ARCH`` is empty.
-   
+
    BUILD_CC_ARCH
       Specifies the architecture-specific C compiler flags for the build
       host. By default, the value of ``BUILD_CC_ARCH`` is empty.
-   
+
    BUILD_CCLD
       Specifies the linker command to be used for the build host when the C
       compiler is being used as the linker. By default, ``BUILD_CCLD``
       points to GCC and passes as arguments the value of
       :term:`BUILD_CC_ARCH`, assuming
       ``BUILD_CC_ARCH`` is set.
-   
+
    BUILD_CFLAGS
       Specifies the flags to pass to the C compiler when building for the
       build host. When building in the ``-native`` context,
       :term:`CFLAGS` is set to the value of this variable by
       default.
-   
+
    BUILD_CPPFLAGS
       Specifies the flags to pass to the C preprocessor (i.e. to both the C
       and the C++ compilers) when building for the build host. When
       building in the ``-native`` context, :term:`CPPFLAGS`
       is set to the value of this variable by default.
-   
+
    BUILD_CXXFLAGS
       Specifies the flags to pass to the C++ compiler when building for the
       build host. When building in the ``-native`` context,
       :term:`CXXFLAGS` is set to the value of this variable
       by default.
-   
+
    BUILD_FC
       Specifies the Fortran compiler command for the build host. By
       default, ``BUILD_FC`` points to Gfortran and passes as arguments the
       value of :term:`BUILD_CC_ARCH`, assuming
       ``BUILD_CC_ARCH`` is set.
-   
+
    BUILD_LD
       Specifies the linker command for the build host. By default,
       ``BUILD_LD`` points to the GNU linker (ld) and passes as arguments
       the value of :term:`BUILD_LD_ARCH`, assuming
       ``BUILD_LD_ARCH`` is set.
-   
+
    BUILD_LD_ARCH
       Specifies architecture-specific linker flags for the build host. By
       default, the value of ``BUILD_LD_ARCH`` is empty.
-   
+
    BUILD_LDFLAGS
       Specifies the flags to pass to the linker when building for the build
       host. When building in the ``-native`` context,
       :term:`LDFLAGS` is set to the value of this variable
       by default.
-   
+
    BUILD_OPTIMIZATION
       Specifies the optimization flags passed to the C compiler when
       building for the build host or the SDK. The flags are passed through
       the :term:`BUILD_CFLAGS` and
       :term:`BUILDSDK_CFLAGS` default values.
-   
+
       The default value of the ``BUILD_OPTIMIZATION`` variable is "-O2
       -pipe".
-   
+
    BUILD_OS
       Specifies the operating system in use on the build host (e.g.
       "linux"). The OpenEmbedded build system sets the value of
       ``BUILD_OS`` from the OS reported by the ``uname`` command - the
       first word, converted to lower-case characters.
-   
+
    BUILD_PREFIX
       The toolchain binary prefix used for native recipes. The OpenEmbedded
       build system uses the ``BUILD_PREFIX`` value to set the
       :term:`TARGET_PREFIX` when building for
       ``native`` recipes.
-   
+
    BUILD_STRIP
       Specifies the command to be used to strip debugging symbols from
       binaries produced for the build host. By default, ``BUILD_STRIP``
       points to
       ``${``\ :term:`BUILD_PREFIX`\ ``}strip``.
-   
+
    BUILD_SYS
       Specifies the system, including the architecture and the operating
       system, to use when building for the build host (i.e. when building
       ``native`` recipes).
-   
+
       The OpenEmbedded build system automatically sets this variable based
       on :term:`BUILD_ARCH`,
       :term:`BUILD_VENDOR`, and
       :term:`BUILD_OS`. You do not need to set the
       ``BUILD_SYS`` variable yourself.
-   
+
    BUILD_VENDOR
       Specifies the vendor name to use when building for the build host.
       The default value is an empty string ("").
-   
+
    BUILDDIR
       Points to the location of the :term:`Build Directory`.
       You can define this directory indirectly through the
@@ -838,7 +948,7 @@ system and gives an overview of their function and contents.
       Directory path when you run the script. If you run the script and do
       not provide a Build Directory path, the ``BUILDDIR`` defaults to
       ``build`` in the current directory.
-   
+
    BUILDHISTORY_COMMIT
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies whether or not to commit the build
@@ -848,60 +958,70 @@ system and gives an overview of their function and contents.
       top-level subdirectory of the build history output (images, packages,
       and sdk). If you want to track changes to build history over time,
       you should set this value to "1".
-   
+
       By default, the ``buildhistory`` class does not commit the build
-      history output in a local Git repository: BUILDHISTORY_COMMIT ?= "0"
-   
+      history output in a local Git repository:
+      ::
+
+         BUILDHISTORY_COMMIT ?= "0"
+
    BUILDHISTORY_COMMIT_AUTHOR
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies the author to use for each Git commit.
       In order for the ``BUILDHISTORY_COMMIT_AUTHOR`` variable to work, the
       :term:`BUILDHISTORY_COMMIT` variable must
       be set to "1".
-   
+
       Git requires that the value you provide for the
       ``BUILDHISTORY_COMMIT_AUTHOR`` variable takes the form of "name
       email@host". Providing an email address or host that is not valid
       does not produce an error.
-   
+
       By default, the ``buildhistory`` class sets the variable as follows:
-      BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
-   
+      ::
+
+         BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
+
    BUILDHISTORY_DIR
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies the directory in which build history
       information is kept. For more information on how the variable works,
       see the ``buildhistory.class``.
-   
+
       By default, the ``buildhistory`` class sets the directory as follows:
-      BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
-   
+      ::
+
+         BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
+
    BUILDHISTORY_FEATURES
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies the build history features to be
       enabled. For more information on how build history works, see the
-      "`Maintaining Build Output
-      Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
       section in the Yocto Project Development Tasks Manual.
-   
+
       You can specify these features in the form of a space-separated list:
-   
+
       -  *image:* Analysis of the contents of images, which includes the
          list of installed packages among other things.
-   
+
       -  *package:* Analysis of the contents of individual packages.
-   
+
       -  *sdk:* Analysis of the contents of the software development kit
          (SDK).
-   
-      -  *task:* Save output file signatures for `shared
-         state <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__ (sstate) tasks.
+
+      -  *task:* Save output file signatures for
+         :ref:`shared state <overview-manual/overview-manual-concepts:shared state cache>`
+         (sstate) tasks.
          This saves one file per task and lists the SHA-256 checksums for
          each file staged (i.e. the output of the task).
-   
+
       By default, the ``buildhistory`` class enables the following
-      features: BUILDHISTORY_FEATURES ?= "image package sdk"
-   
+      features:
+      ::
+
+         BUILDHISTORY_FEATURES ?= "image package sdk"
+
    BUILDHISTORY_IMAGE_FILES
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies a list of paths to files copied from
@@ -912,10 +1032,13 @@ system and gives an overview of their function and contents.
       changes in user and group entries. You can modify the list to include
       any file. Specifying an invalid path does not produce an error.
       Consequently, you can include files that might not always be present.
-   
+
       By default, the ``buildhistory`` class provides paths to the
-      following files: BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
-   
+      following files:
+      ::
+
+         BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
+
    BUILDHISTORY_PUSH_REPO
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable optionally specifies a remote repository to
@@ -923,81 +1046,83 @@ system and gives an overview of their function and contents.
       ``BUILDHISTORY_PUSH_REPO`` to work,
       :term:`BUILDHISTORY_COMMIT` must be set to
       "1".
-   
+
       The repository should correspond to a remote address that specifies a
       repository as understood by Git, or alternatively to a remote name
       that you have set up manually using ``git remote`` within the local
       repository.
-   
+
       By default, the ``buildhistory`` class sets the variable as follows:
-      BUILDHISTORY_PUSH_REPO ?= ""
-   
+      ::
+
+         BUILDHISTORY_PUSH_REPO ?= ""
+
    BUILDSDK_CFLAGS
       Specifies the flags to pass to the C compiler when building for the
       SDK. When building in the ``nativesdk-`` context,
       :term:`CFLAGS` is set to the value of this variable by
       default.
-   
+
    BUILDSDK_CPPFLAGS
       Specifies the flags to pass to the C pre-processor (i.e. to both the
       C and the C++ compilers) when building for the SDK. When building in
       the ``nativesdk-`` context, :term:`CPPFLAGS` is set
       to the value of this variable by default.
-   
+
    BUILDSDK_CXXFLAGS
       Specifies the flags to pass to the C++ compiler when building for the
       SDK. When building in the ``nativesdk-`` context,
       :term:`CXXFLAGS` is set to the value of this variable
       by default.
-   
+
    BUILDSDK_LDFLAGS
       Specifies the flags to pass to the linker when building for the SDK.
       When building in the ``nativesdk-`` context,
       :term:`LDFLAGS` is set to the value of this variable
       by default.
-   
+
    BUILDSTATS_BASE
       Points to the location of the directory that holds build statistics
       when you use and enable the
       :ref:`buildstats <ref-classes-buildstats>` class. The
       ``BUILDSTATS_BASE`` directory defaults to
       ``${``\ :term:`TMPDIR`\ ``}/buildstats/``.
-   
+
    BUSYBOX_SPLIT_SUID
       For the BusyBox recipe, specifies whether to split the output
       executable file into two parts: one for features that require
       ``setuid root``, and one for the remaining features (i.e. those that
       do not require ``setuid root``).
-   
+
       The ``BUSYBOX_SPLIT_SUID`` variable defaults to "1", which results in
       splitting the output executable file. Set the variable to "0" to get
       a single output executable file.
-   
+
    CACHE
       Specifies the directory BitBake uses to store a cache of the
       :term:`Metadata` so it does not need to be parsed every time
       BitBake is started.
-   
+
    CC
       The minimal command and arguments used to run the C compiler.
-   
+
    CFLAGS
       Specifies the flags to pass to the C compiler. This variable is
       exported to an environment variable and thus made visible to the
       software being built during the compilation step.
-   
+
       Default initialization for ``CFLAGS`` varies depending on what is
       being built:
-   
+
       -  :term:`TARGET_CFLAGS` when building for the
          target
-   
+
       -  :term:`BUILD_CFLAGS` when building for the
          build host (i.e. ``-native``)
-   
+
       -  :term:`BUILDSDK_CFLAGS` when building for
          an SDK (i.e. ``nativesdk-``)
-   
+
    CLASSOVERRIDE
       An internal variable specifying the special class override that
       should currently apply (e.g. "class-target", "class-native", and so
@@ -1005,31 +1130,41 @@ system and gives an overview of their function and contents.
       :ref:`native <ref-classes-native>`,
       :ref:`nativesdk <ref-classes-nativesdk>`, and so forth) set the
       variable to appropriate values.
-   
+
       .. note::
-   
+
          CLASSOVERRIDE
          gets its default "class-target" value from the
          bitbake.conf
          file.
-   
+
       As an example, the following override allows you to install extra
       files, but only when building for the target:
-      do_install_append_class-target() { install my-extra-file
-      ${D}${sysconfdir} } Here is an example where ``FOO`` is set to
+      ::
+
+         do_install_append_class-target() {
+             install my-extra-file ${D}${sysconfdir}
+         }
+
+      Here is an example where ``FOO`` is set to
       "native" when building for the build host, and to "other" when not
-      building for the build host: FOO_class-native = "native" FOO =
-      "other" The underlying mechanism behind ``CLASSOVERRIDE`` is simply
+      building for the build host:
+      ::
+
+         FOO_class-native = "native"
+         FOO = "other"
+
+      The underlying mechanism behind ``CLASSOVERRIDE`` is simply
       that it is included in the default value of
       :term:`OVERRIDES`.
-   
+
    CLEANBROKEN
       If set to "1" within a recipe, ``CLEANBROKEN`` specifies that the
       ``make clean`` command does not work for the software being built.
       Consequently, the OpenEmbedded build system will not try to run
       ``make clean`` during the :ref:`ref-tasks-configure`
       task, which is the default behavior.
-   
+
    COMBINED_FEATURES
       Provides a list of hardware features that are enabled in both
       :term:`MACHINE_FEATURES` and
@@ -1039,12 +1174,12 @@ system and gives an overview of their function and contents.
       "bluetooth" feature requires hardware support but should also be
       optional at the distribution level, in case the hardware supports
       Bluetooth but you do not ever intend to use it.
-   
+
    COMMON_LICENSE_DIR
       Points to ``meta/files/common-licenses`` in the
       :term:`Source Directory`, which is where generic license
       files reside.
-   
+
    COMPATIBLE_HOST
       A regular expression that resolves to one or more hosts (when the
       recipe is native) or one or more targets (when the recipe is
@@ -1055,7 +1190,7 @@ system and gives an overview of their function and contents.
       particularly useful with kernels. The variable also helps to increase
       parsing speed since the build system skips parsing recipes not
       compatible with the current system.
-   
+
    COMPATIBLE_MACHINE
       A regular expression that resolves to one or more target machines
       with which a recipe is compatible. The regular expression is matched
@@ -1065,14 +1200,14 @@ system and gives an overview of their function and contents.
       useful with kernels. The variable also helps to increase parsing
       speed since the build system skips parsing recipes not compatible
       with the current machine.
-   
+
    COMPLEMENTARY_GLOB
       Defines wildcards to match when installing a list of complementary
       packages for all the packages explicitly (or implicitly) installed in
       an image.
-   
+
       .. note::
-   
+
          The
          COMPLEMENTARY_GLOB
          variable uses Unix filename pattern matching (
@@ -1080,33 +1215,36 @@ system and gives an overview of their function and contents.
          ), which is similar to the Unix style pathname pattern expansion (
          glob
          ).
-   
+
       The resulting list of complementary packages is associated with an
       item that can be added to
       :term:`IMAGE_FEATURES`. An example usage of
       this is the "dev-pkgs" item that when added to ``IMAGE_FEATURES``
       will install -dev packages (containing headers and other development
       files) for every package in the image.
-   
+
       To add a new feature item pointing to a wildcard, use a variable flag
       to specify the feature item name and use the value to specify the
-      wildcard. Here is an example: COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
-   
+      wildcard. Here is an example:
+      ::
+
+         COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
+
    COMPONENTS_DIR
       Stores sysroot components for each recipe. The OpenEmbedded build
       system uses ``COMPONENTS_DIR`` when constructing recipe-specific
       sysroots for other recipes.
-   
+
       The default is
       "``${``\ :term:`STAGING_DIR`\ ``}-components``."
       (i.e.
       "``${``\ :term:`TMPDIR`\ ``}/sysroots-components``").
-   
+
    CONF_VERSION
       Tracks the version of the local configuration file (i.e.
       ``local.conf``). The value for ``CONF_VERSION`` increments each time
       ``build/conf/`` compatibility changes.
-   
+
    CONFFILES
       Identifies editable or configurable files that are part of a package.
       If the Package Management System (PMS) is being used to update
@@ -1117,12 +1255,15 @@ system and gives an overview of their function and contents.
       as part of the package update process. You can use the ``CONFFILES``
       variable to list the files in the package that you wish to prevent
       the PMS from overwriting during this update process.
-   
+
       To use the ``CONFFILES`` variable, provide a package name override
       that identifies the resulting package. Then, provide a
-      space-separated list of files. Here is an example: CONFFILES_${PN} +=
-      "${sysconfdir}/file1 \\ ${sysconfdir}/file2 ${sysconfdir}/file3"
-   
+      space-separated list of files. Here is an example:
+      ::
+
+         CONFFILES_${PN} += "${sysconfdir}/file1 \
+             ${sysconfdir}/file2 ${sysconfdir}/file3"
+
       A relationship exists between the ``CONFFILES`` and ``FILES``
       variables. The files listed within ``CONFFILES`` must be a subset of
       the files listed within ``FILES``. Because the configuration files
@@ -1130,9 +1271,9 @@ system and gives an overview of their function and contents.
       the PMS will not overwrite them, it makes sense that the files must
       already be included as part of the package through the ``FILES``
       variable.
-   
+
       .. note::
-   
+
          When specifying paths as part of the
          CONFFILES
          variable, it is good practice to use appropriate path variables.
@@ -1149,13 +1290,13 @@ system and gives an overview of their function and contents.
          file in the
          Source Directory
          .
-   
+
    CONFIG_INITRAMFS_SOURCE
       Identifies the initial RAM filesystem (initramfs) source files. The
       OpenEmbedded build system receives and uses this kernel Kconfig
       variable as an environment variable. By default, the variable is set
       to null ("").
-   
+
       The ``CONFIG_INITRAMFS_SOURCE`` can be either a single cpio archive
       with a ``.cpio`` suffix or a space-separated list of directories and
       files for building the initramfs image. A cpio archive should contain
@@ -1163,23 +1304,22 @@ system and gives an overview of their function and contents.
       should contain a filesystem layout to be included in the initramfs
       image. Files should contain entries according to the format described
       by the ``usr/gen_init_cpio`` program in the kernel tree.
-   
+
       If you specify multiple directories and files, the initramfs image
       will be the aggregate of all of them.
-   
-      For information on creating an initramfs, see the "`Building an
-      Initial RAM Filesystem (initramfs)
-      Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section
+
+      For information on creating an initramfs, see the
+      ":ref:`building-an-initramfs-image`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    CONFIG_SITE
       A list of files that contains ``autoconf`` test results relevant to
       the current build. This variable is used by the Autotools utilities
       when running ``configure``.
-   
+
    CONFIGURE_FLAGS
       The minimal arguments for GNU configure.
-   
+
    CONFLICT_DISTRO_FEATURES
       When inheriting the
       :ref:`distro_features_check <ref-classes-distro_features_check>`
@@ -1188,7 +1328,7 @@ system and gives an overview of their function and contents.
       ``CONFLICT_DISTRO_FEATURES`` variable lists a feature that also
       appears in ``DISTRO_FEATURES`` within the current configuration, an
       error occurs and the build stops.
-   
+
    COPYLEFT_LICENSE_EXCLUDE
       A space-separated list of licenses to exclude from the source
       archived by the :ref:`archiver <ref-classes-archiver>` class. In
@@ -1196,32 +1336,32 @@ system and gives an overview of their function and contents.
       :term:`LICENSE` value is in the value of
       ``COPYLEFT_LICENSE_EXCLUDE``, then its source is not archived by the
       class.
-   
+
       .. note::
-   
+
          The
          COPYLEFT_LICENSE_EXCLUDE
          variable takes precedence over the
          COPYLEFT_LICENSE_INCLUDE
          variable.
-   
+
       The default value, which is "CLOSED Proprietary", for
       ``COPYLEFT_LICENSE_EXCLUDE`` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
       is inherited by the ``archiver`` class.
-   
+
    COPYLEFT_LICENSE_INCLUDE
       A space-separated list of licenses to include in the source archived
       by the :ref:`archiver <ref-classes-archiver>` class. In other
       words, if a license in a recipe's :term:`LICENSE`
       value is in the value of ``COPYLEFT_LICENSE_INCLUDE``, then its
       source is archived by the class.
-   
+
       The default value is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
       is inherited by the ``archiver`` class. The default value includes
       "GPL*", "LGPL*", and "AGPL*".
-   
+
    COPYLEFT_PN_EXCLUDE
       A list of recipes to exclude in the source archived by the
       :ref:`archiver <ref-classes-archiver>` class. The
@@ -1230,12 +1370,12 @@ system and gives an overview of their function and contents.
       :term:`COPYLEFT_LICENSE_INCLUDE` and
       :term:`COPYLEFT_LICENSE_EXCLUDE`
       variables, respectively.
-   
+
       The default value, which is "" indicating to not explicitly exclude
       any recipes by name, for ``COPYLEFT_PN_EXCLUDE`` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
       is inherited by the ``archiver`` class.
-   
+
    COPYLEFT_PN_INCLUDE
       A list of recipes to include in the source archived by the
       :ref:`archiver <ref-classes-archiver>` class. The
@@ -1244,22 +1384,22 @@ system and gives an overview of their function and contents.
       :term:`COPYLEFT_LICENSE_INCLUDE` and
       :term:`COPYLEFT_LICENSE_EXCLUDE`
       variables, respectively.
-   
+
       The default value, which is "" indicating to not explicitly include
       any recipes by name, for ``COPYLEFT_PN_INCLUDE`` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
       is inherited by the ``archiver`` class.
-   
+
    COPYLEFT_RECIPE_TYPES
       A space-separated list of recipe types to include in the source
       archived by the :ref:`archiver <ref-classes-archiver>` class.
       Recipe types are ``target``, ``native``, ``nativesdk``, ``cross``,
       ``crosssdk``, and ``cross-canadian``.
-   
+
       The default value, which is "target*", for ``COPYLEFT_RECIPE_TYPES``
       is set by the :ref:`copyleft_filter <ref-classes-copyleft_filter>`
       class, which is inherited by the ``archiver`` class.
-   
+
    COPY_LIC_DIRS
       If set to "1" along with the
       :term:`COPY_LIC_MANIFEST` variable, the
@@ -1267,9 +1407,9 @@ system and gives an overview of their function and contents.
       which are located in ``/usr/share/common-licenses``, for each
       package. The license files are placed in directories within the image
       itself during build time.
-   
+
       .. note::
-   
+
          The
          COPY_LIC_DIRS
          does not offer a path for adding licenses for newly installed
@@ -1280,15 +1420,15 @@ system and gives an overview of their function and contents.
          Providing License Text
          " section in the Yocto Project Development Tasks Manual for
          information on providing license text.
-   
+
    COPY_LIC_MANIFEST
       If set to "1", the OpenEmbedded build system copies the license
       manifest for the image to
       ``/usr/share/common-licenses/license.manifest`` within the image
       itself during build time.
-   
+
       .. note::
-   
+
          The
          COPY_LIC_MANIFEST
          does not offer a path for adding licenses for newly installed
@@ -1299,177 +1439,190 @@ system and gives an overview of their function and contents.
          Providing License Text
          " section in the Yocto Project Development Tasks Manual for
          information on providing license text.
-   
+
    CORE_IMAGE_EXTRA_INSTALL
       Specifies the list of packages to be added to the image. You should
       only set this variable in the ``local.conf`` configuration file found
       in the :term:`Build Directory`.
-   
+
       This variable replaces ``POKY_EXTRA_INSTALL``, which is no longer
       supported.
-   
+
    COREBASE
       Specifies the parent directory of the OpenEmbedded-Core Metadata
       layer (i.e. ``meta``).
-   
+
       It is an important distinction that ``COREBASE`` points to the parent
       of this layer and not the layer itself. Consider an example where you
       have cloned the Poky Git repository and retained the ``poky`` name
       for your local copy of the repository. In this case, ``COREBASE``
       points to the ``poky`` folder because it is the parent directory of
       the ``poky/meta`` layer.
-   
+
    COREBASE_FILES
       Lists files from the :term:`COREBASE` directory that
       should be copied other than the layers listed in the
       ``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for
       the purpose of copying metadata from the OpenEmbedded build system
       into the extensible SDK.
-   
+
       Explicitly listing files in ``COREBASE`` is needed because it
       typically contains build directories and other files that should not
       normally be copied into the extensible SDK. Consequently, the value
       of ``COREBASE_FILES`` is used in order to only copy the files that
       are actually needed.
-   
+
    CPP
       The minimal command and arguments used to run the C preprocessor.
-   
+
    CPPFLAGS
       Specifies the flags to pass to the C pre-processor (i.e. to both the
       C and the C++ compilers). This variable is exported to an environment
       variable and thus made visible to the software being built during the
       compilation step.
-   
+
       Default initialization for ``CPPFLAGS`` varies depending on what is
       being built:
-   
+
       -  :term:`TARGET_CPPFLAGS` when building for
          the target
-   
+
       -  :term:`BUILD_CPPFLAGS` when building for the
          build host (i.e. ``-native``)
-   
+
       -  :term:`BUILDSDK_CPPFLAGS` when building
          for an SDK (i.e. ``nativesdk-``)
-   
+
    CROSS_COMPILE
       The toolchain binary prefix for the target tools. The
       ``CROSS_COMPILE`` variable is the same as the
       :term:`TARGET_PREFIX` variable.
-   
+
       .. note::
-   
+
          The OpenEmbedded build system sets the
          CROSS_COMPILE
          variable only in certain contexts (e.g. when building for kernel
          and kernel module recipes).
-   
+
    CVSDIR
       The directory in which files checked out under the CVS system are
       stored.
-   
+
    CXX
       The minimal command and arguments used to run the C++ compiler.
-   
+
    CXXFLAGS
       Specifies the flags to pass to the C++ compiler. This variable is
       exported to an environment variable and thus made visible to the
       software being built during the compilation step.
-   
+
       Default initialization for ``CXXFLAGS`` varies depending on what is
       being built:
-   
+
       -  :term:`TARGET_CXXFLAGS` when building for
          the target
-   
+
       -  :term:`BUILD_CXXFLAGS` when building for the
          build host (i.e. ``-native``)
-   
+
       -  :term:`BUILDSDK_CXXFLAGS` when building
          for an SDK (i.e. ``nativesdk-``)
-   
+
    D
       The destination directory. The location in the :term:`Build Directory`
       where components are installed by the
       :ref:`ref-tasks-install` task. This location defaults
-      to: ${WORKDIR}/image
-   
+      to:
+      ::
+
+         ${WORKDIR}/image
+
       .. note::
-   
+
          Tasks that read from or write to this directory should run under
          fakeroot
          .
-   
+
    DATE
       The date the build was started. Dates appear using the year, month,
       and day (YMD) format (e.g. "20150209" for February 9th, 2015).
-   
+
    DATETIME
       The date and time on which the current build started. The format is
       suitable for timestamps.
-   
+
    DEBIAN_NOAUTONAME
       When the :ref:`debian <ref-classes-debian>` class is inherited,
       which is the default behavior, ``DEBIAN_NOAUTONAME`` specifies a
       particular package should not be renamed according to Debian library
       package naming. You must use the package name as an override when you
       set this variable. Here is an example from the ``fontconfig`` recipe:
-      DEBIAN_NOAUTONAME_fontconfig-utils = "1"
-   
+      ::
+
+         DEBIAN_NOAUTONAME_fontconfig-utils = "1"
+
    DEBIANNAME
       When the :ref:`debian <ref-classes-debian>` class is inherited,
       which is the default behavior, ``DEBIANNAME`` allows you to override
       the library name for an individual package. Overriding the library
       name in these cases is rare. You must use the package name as an
       override when you set this variable. Here is an example from the
-      ``dbus`` recipe: DEBIANNAME_${PN} = "dbus-1"
-   
+      ``dbus`` recipe:
+      ::
+
+         DEBIANNAME_${PN} = "dbus-1"
+
    DEBUG_BUILD
       Specifies to build packages with debugging information. This
       influences the value of the ``SELECTED_OPTIMIZATION`` variable.
-   
+
    DEBUG_OPTIMIZATION
       The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when
       compiling a system for debugging. This variable defaults to "-O
       -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe".
-   
+
    DEFAULT_PREFERENCE
       Specifies a weak bias for recipe selection priority.
-   
+
       The most common usage of this is variable is to set it to "-1" within
       a recipe for a development version of a piece of software. Using the
       variable in this way causes the stable version of the recipe to build
       by default in the absence of ``PREFERRED_VERSION`` being used to
       build the development version.
-   
+
       .. note::
-   
+
          The bias provided by
          DEFAULT_PREFERENCE
          is weak and is overridden by
          BBFILE_PRIORITY
          if that variable is different between two layers that contain
          different versions of the same recipe.
-   
+
    DEFAULTTUNE
       The default CPU and Application Binary Interface (ABI) tunings (i.e.
       the "tune") used by the OpenEmbedded build system. The
       ``DEFAULTTUNE`` helps define
       :term:`TUNE_FEATURES`.
-   
+
       The default tune is either implicitly or explicitly set by the
       machine (:term:`MACHINE`). However, you can override
       the setting using available tunes as defined with
       :term:`AVAILTUNES`.
-   
+
    DEPENDS
       Lists a recipe's build-time dependencies. These are dependencies on
       other recipes whose contents (e.g. headers and shared libraries) are
       needed by the recipe at build time.
-   
+
       As an example, consider a recipe ``foo`` that contains the following
-      assignment: DEPENDS = "bar" The practical effect of the previous
+      assignment:
+      ::
+
+          DEPENDS = "bar"
+
+      The practical effect of the previous
       assignment is that all files installed by bar will be available in
       the appropriate staging sysroot, given by the
       :term:`STAGING_DIR* <STAGING_DIR>` variables, by the time the
@@ -1479,23 +1632,28 @@ system and gives an overview of their function and contents.
       each recipe listed in ``DEPENDS``, through a
       ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
       declaration in the :ref:`base <ref-classes-base>` class.
-   
+
       .. note::
-   
+
          It seldom is necessary to reference, for example,
          STAGING_DIR_HOST
          explicitly. The standard classes and build-related variables are
          configured to automatically use the appropriate staging sysroots.
-   
+
       As another example, ``DEPENDS`` can also be used to add utilities
       that run on the build machine during the build. For example, a recipe
       that makes use of a code generator built by the recipe ``codegen``
-      might have the following: DEPENDS = "codegen-native" For more
+      might have the following:
+      ::
+
+         DEPENDS = "codegen-native"
+
+      For more
       information, see the :ref:`native <ref-classes-native>` class and
       the :term:`EXTRANATIVEPATH` variable.
-   
+
       .. note::
-   
+
          -  ``DEPENDS`` is a list of recipe names. Or, to be more precise,
             it is a list of :term:`PROVIDES` names, which
             usually match recipe names. Putting a package name such as
@@ -1503,16 +1661,15 @@ system and gives an overview of their function and contents.
             instead, as this will put files from all the packages that make
             up ``foo``, which includes those from ``foo-dev``, into the
             sysroot.
-   
+
          -  One recipe having another recipe in ``DEPENDS`` does not by
             itself add any runtime dependencies between the packages
             produced by the two recipes. However, as explained in the
-            "`Automatically Added Runtime
-            Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+            ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
             section in the Yocto Project Overview and Concepts Manual,
             runtime dependencies will often be added automatically, meaning
             ``DEPENDS`` alone is sufficient for most recipes.
-   
+
          -  Counterintuitively, ``DEPENDS`` is often necessary even for
             recipes that install precompiled components. For example, if
             ``libfoo`` is a precompiled library that links against
@@ -1521,50 +1678,51 @@ system and gives an overview of their function and contents.
             Without a ``DEPENDS`` from the recipe that installs ``libfoo``
             to the recipe that installs ``libbar``, other recipes might
             fail to link against ``libfoo``.
-   
+
       For information on runtime dependencies, see the
       :term:`RDEPENDS` variable. You can also see the
       ":ref:`Tasks <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks>`" and
       ":ref:`Dependencies <bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies>`" sections in the
       BitBake User Manual for additional information on tasks and
       dependencies.
-   
+
    DEPLOY_DIR
       Points to the general area that the OpenEmbedded build system uses to
       place images, packages, SDKs, and other output files that are ready
       to be used outside of the build system. By default, this directory
       resides within the :term:`Build Directory` as
       ``${TMPDIR}/deploy``.
-   
+
       For more information on the structure of the Build Directory, see
-      "`The Build Directory - ``build/`` <#structure-build>`__" section.
+      ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
       For more detail on the contents of the ``deploy`` directory, see the
-      "`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__", "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__", and
-      "`Application Development
-      SDK <&YOCTO_DOCS_OM_URL;#sdk-dev-environment>`__" sections all in the
+      ":ref:`Images <images-dev-environment>`", ":ref:`Package
+      Feeds <package-feeds-dev-environment>`", and
+      ":ref:`sdk-dev-environment`" sections all in the
       Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_DEB
       Points to the area that the OpenEmbedded build system uses to place
       Debian packages that are ready to be used outside of the build
       system. This variable applies only when
       :term:`PACKAGE_CLASSES` contains
       "package_deb".
-   
+
       The BitBake configuration file initially defines the
       ``DEPLOY_DIR_DEB`` variable as a sub-folder of
-      :term:`DEPLOY_DIR`: DEPLOY_DIR_DEB =
-      "${DEPLOY_DIR}/deb"
-   
+      :term:`DEPLOY_DIR`:
+      ::
+
+         DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
+
       The :ref:`package_deb <ref-classes-package_deb>` class uses the
       ``DEPLOY_DIR_DEB`` variable to make sure the
       :ref:`ref-tasks-package_write_deb` task
       writes Debian packages into the appropriate folder. For more
-      information on how packaging works, see the "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
+      information on how packaging works, see the ":ref:`Package
+      Feeds <package-feeds-dev-environment>`" section
       in the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_IMAGE
       Points to the area that the OpenEmbedded build system uses to place
       images and other associated output files that are ready to be
@@ -1572,120 +1730,130 @@ system and gives an overview of their function and contents.
       as it contains the ``${MACHINE}`` name. By default, this directory
       resides within the :term:`Build Directory` as
       ``${DEPLOY_DIR}/images/${MACHINE}/``.
-   
+
       For more information on the structure of the Build Directory, see
-      "`The Build Directory - ``build/`` <#structure-build>`__" section.
+      ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
       For more detail on the contents of the ``deploy`` directory, see the
-      "`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" and
-      "`Application Development
-      SDK <&YOCTO_DOCS_OM_URL;#sdk-dev-environment>`__" sections both in
+      ":ref:`Images <images-dev-environment>`" and
+      ":ref:`sdk-dev-environment`" sections both in
       the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_IPK
       Points to the area that the OpenEmbedded build system uses to place
       IPK packages that are ready to be used outside of the build system.
       This variable applies only when
       :term:`PACKAGE_CLASSES` contains
       "package_ipk".
-   
+
       The BitBake configuration file initially defines this variable as a
-      sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_IPK =
-      "${DEPLOY_DIR}/ipk"
-   
+      sub-folder of :term:`DEPLOY_DIR`:
+      ::
+
+         DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
+
       The :ref:`package_ipk <ref-classes-package_ipk>` class uses the
       ``DEPLOY_DIR_IPK`` variable to make sure the
       :ref:`ref-tasks-package_write_ipk` task
       writes IPK packages into the appropriate folder. For more information
-      on how packaging works, see the "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
+      on how packaging works, see the ":ref:`Package
+      Feeds <package-feeds-dev-environment>`" section
       in the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_RPM
       Points to the area that the OpenEmbedded build system uses to place
       RPM packages that are ready to be used outside of the build system.
       This variable applies only when
       :term:`PACKAGE_CLASSES` contains
       "package_rpm".
-   
+
       The BitBake configuration file initially defines this variable as a
-      sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_RPM =
-      "${DEPLOY_DIR}/rpm"
-   
+      sub-folder of :term:`DEPLOY_DIR`:
+      ::
+
+         DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
+
       The :ref:`package_rpm <ref-classes-package_rpm>` class uses the
       ``DEPLOY_DIR_RPM`` variable to make sure the
       :ref:`ref-tasks-package_write_rpm` task
       writes RPM packages into the appropriate folder. For more information
-      on how packaging works, see the "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
+      on how packaging works, see the ":ref:`Package
+      Feeds <package-feeds-dev-environment>`" section
       in the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_TAR
       Points to the area that the OpenEmbedded build system uses to place
       tarballs that are ready to be used outside of the build system. This
       variable applies only when
       :term:`PACKAGE_CLASSES` contains
       "package_tar".
-   
+
       The BitBake configuration file initially defines this variable as a
-      sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_TAR =
-      "${DEPLOY_DIR}/tar"
-   
+      sub-folder of :term:`DEPLOY_DIR`:
+      ::
+
+         DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar"
+
       The :ref:`package_tar <ref-classes-package_tar>` class uses the
       ``DEPLOY_DIR_TAR`` variable to make sure the
       :ref:`ref-tasks-package_write_tar` task
       writes TAR packages into the appropriate folder. For more information
-      on how packaging works, see the "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
+      on how packaging works, see the ":ref:`Package
+      Feeds <package-feeds-dev-environment>`" section
       in the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOYDIR
       When inheriting the :ref:`deploy <ref-classes-deploy>` class, the
       ``DEPLOYDIR`` points to a temporary work area for deployed files that
-      is set in the ``deploy`` class as follows: DEPLOYDIR =
-      "${WORKDIR}/deploy-${:term:`PN`}"
-   
+      is set in the ``deploy`` class as follows:
+      ::
+
+         DEPLOYDIR = "${WORKDIR}/deploy-${:term:`PN`}"
+
       Recipes inheriting the ``deploy`` class should copy files to be
       deployed into ``DEPLOYDIR``, and the class will take care of copying
       them into :term:`DEPLOY_DIR_IMAGE`
       afterwards.
-   
+
    DESCRIPTION
       The package description used by package managers. If not set,
       ``DESCRIPTION`` takes the value of the :term:`SUMMARY`
       variable.
-   
+
    DISTRO
       The short name of the distribution. For information on the long name
       of the distribution, see the :term:`DISTRO_NAME`
       variable.
-   
+
       The ``DISTRO`` variable corresponds to a distribution configuration
       file whose root name is the same as the variable's argument and whose
       filename extension is ``.conf``. For example, the distribution
       configuration file for the Poky distribution is named ``poky.conf``
       and resides in the ``meta-poky/conf/distro`` directory of the
       :term:`Source Directory`.
-   
+
       Within that ``poky.conf`` file, the ``DISTRO`` variable is set as
-      follows: DISTRO = "poky"
-   
+      follows:
+      ::
+
+         DISTRO = "poky"
+
       Distribution configuration files are located in a ``conf/distro``
       directory within the :term:`Metadata` that contains the
       distribution configuration. The value for ``DISTRO`` must not contain
       spaces, and is typically all lower-case.
-   
+
       .. note::
-   
+
          If the
          DISTRO
          variable is blank, a set of default configurations are used, which
          are specified within
          meta/conf/distro/defaultsetup.conf
          also in the Source Directory.
-   
+
    DISTRO_CODENAME
       Specifies a codename for the distribution being built.
-   
+
    DISTRO_EXTRA_RDEPENDS
       Specifies a list of distro-specific packages to add to all images.
       This variable takes affect through ``packagegroup-base`` so the
@@ -1693,18 +1861,18 @@ system and gives an overview of their function and contents.
       include ``packagegroup-base``. You can use this variable to keep
       distro policy out of generic images. As with all other distro
       variables, you set this variable in the distro ``.conf`` file.
-   
+
    DISTRO_EXTRA_RRECOMMENDS
       Specifies a list of distro-specific packages to add to all images if
       the packages exist. The packages might not exist or be empty (e.g.
       kernel modules). The list of packages are automatically installed but
       you can remove them.
-   
+
    DISTRO_FEATURES
       The software support you want in your distribution for various
       features. You define your distribution features in the distribution
       configuration file.
-   
+
       In most cases, the presence or absence of a feature in
       ``DISTRO_FEATURES`` is translated to the appropriate option supplied
       to the configure script during the
@@ -1713,41 +1881,43 @@ system and gives an overview of their function and contents.
       ``DISTRO_FEATURES``, causes every piece of software built for the
       target that can optionally support X11 to have its X11 support
       enabled.
-   
+
       Two more examples are Bluetooth and NFS support. For a more complete
       list of features that ships with the Yocto Project and that you can
       provide with this variable, see the "`Distro
       Features <#ref-features-distro>`__" section.
-   
+
    DISTRO_FEATURES_BACKFILL
       Features to be added to ``DISTRO_FEATURES`` if not also present in
       ``DISTRO_FEATURES_BACKFILL_CONSIDERED``.
-   
+
       This variable is set in the ``meta/conf/bitbake.conf`` file. It is
       not intended to be user-configurable. It is best to just reference
       the variable to see which distro features are being backfilled for
       all distro configurations. See the "`Feature
       Backfilling <#ref-features-backfill>`__" section for more
       information.
-   
+
    DISTRO_FEATURES_BACKFILL_CONSIDERED
       Features from ``DISTRO_FEATURES_BACKFILL`` that should not be
       backfilled (i.e. added to ``DISTRO_FEATURES``) during the build. See
       the "`Feature Backfilling <#ref-features-backfill>`__" section for
       more information.
-   
+
    DISTRO_FEATURES_DEFAULT
       A convenience variable that gives you the default list of distro
       features with the exception of any features specific to the C library
       (``libc``).
-   
+
       When creating a custom distribution, you might find it useful to be
       able to reuse the default
       :term:`DISTRO_FEATURES` options without the
       need to write out the full set. Here is an example that uses
       ``DISTRO_FEATURES_DEFAULT`` from a custom distro configuration file:
-      DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature"
-   
+      ::
+
+         DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature"
+
    DISTRO_FEATURES_FILTER_NATIVE
       Specifies a list of features that if present in the target
       :term:`DISTRO_FEATURES` value should be
@@ -1755,7 +1925,7 @@ system and gives an overview of their function and contents.
       variable is used in addition to the features filtered using the
       :term:`DISTRO_FEATURES_NATIVE`
       variable.
-   
+
    DISTRO_FEATURES_FILTER_NATIVESDK
       Specifies a list of features that if present in the target
       :term:`DISTRO_FEATURES` value should be
@@ -1763,7 +1933,7 @@ system and gives an overview of their function and contents.
       variable is used in addition to the features filtered using the
       :term:`DISTRO_FEATURES_NATIVESDK`
       variable.
-   
+
    DISTRO_FEATURES_NATIVE
       Specifies a list of features that should be included in
       :term:`DISTRO_FEATURES` when building native
@@ -1771,7 +1941,7 @@ system and gives an overview of their function and contents.
       using the
       :term:`DISTRO_FEATURES_FILTER_NATIVE`
       variable.
-   
+
    DISTRO_FEATURES_NATIVESDK
       Specifies a list of features that should be included in
       :term:`DISTRO_FEATURES` when building
@@ -1779,49 +1949,52 @@ system and gives an overview of their function and contents.
       filtered using the
       :term:`DISTRO_FEATURES_FILTER_NATIVESDK`
       variable.
-   
+
    DISTRO_NAME
       The long name of the distribution. For information on the short name
       of the distribution, see the :term:`DISTRO` variable.
-   
+
       The ``DISTRO_NAME`` variable corresponds to a distribution
       configuration file whose root name is the same as the variable's
       argument and whose filename extension is ``.conf``. For example, the
       distribution configuration file for the Poky distribution is named
       ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory
       of the :term:`Source Directory`.
-   
+
       Within that ``poky.conf`` file, the ``DISTRO_NAME`` variable is set
-      as follows: DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-   
+      as follows:
+      ::
+
+         DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
+
       Distribution configuration files are located in a ``conf/distro``
       directory within the :term:`Metadata` that contains the
       distribution configuration.
-   
+
       .. note::
-   
+
          If the
          DISTRO_NAME
          variable is blank, a set of default configurations are used, which
          are specified within
          meta/conf/distro/defaultsetup.conf
          also in the Source Directory.
-   
+
    DISTRO_VERSION
       The version of the distribution.
-   
+
    DISTROOVERRIDES
       A colon-separated list of overrides specific to the current
       distribution. By default, this list includes the value of
       :term:`DISTRO`.
-   
+
       You can extend ``DISTROOVERRIDES`` to add extra overrides that should
       apply to the distribution.
-   
+
       The underlying mechanism behind ``DISTROOVERRIDES`` is simply that it
       is included in the default value of
       :term:`OVERRIDES`.
-   
+
    DL_DIR
       The central download directory used by the build process to store
       downloads. By default, ``DL_DIR`` gets files suitable for mirroring
@@ -1829,25 +2002,29 @@ system and gives an overview of their function and contents.
       repositories, use the
       :term:`BB_GENERATE_MIRROR_TARBALLS`
       variable.
-   
+
       You can set this directory by defining the ``DL_DIR`` variable in the
       ``conf/local.conf`` file. This directory is self-maintaining and you
       should not have to touch it. By default, the directory is
-      ``downloads`` in the :term:`Build Directory`. #DL_DIR
-      ?= "${TOPDIR}/downloads" To specify a different download directory,
+      ``downloads`` in the :term:`Build Directory`.
+      ::
+
+         #DL_DIR ?= "${TOPDIR}/downloads"
+
+      To specify a different download directory,
       simply remove the comment from the line and provide your directory.
-   
+
       During a first build, the system downloads many different source code
       tarballs from various upstream projects. Downloading can take a
       while, particularly if your network connection is slow. Tarballs are
       all stored in the directory defined by ``DL_DIR`` and the build
       system looks there first to find source tarballs.
-   
+
       .. note::
-   
+
          When wiping and rebuilding, you can preserve this directory to
          speed up this part of subsequent builds.
-   
+
       You can safely share this directory between multiple builds on the
       same development machine. For additional information on how the build
       process gets source files when working behind a firewall or proxy
@@ -1856,58 +2033,61 @@ system and gives an overview of their function and contents.
       chapter. You can also refer to the
       ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
       Wiki page.
-   
+
    DOC_COMPRESS
       When inheriting the :ref:`compress_doc <ref-classes-compress_doc>`
       class, this variable sets the compression policy used when the
       OpenEmbedded build system compresses man pages and info pages. By
       default, the compression method used is gz (gzip). Other policies
       available are xz and bz2.
-   
+
       For information on policies and on how to use this variable, see the
       comments in the ``meta/classes/compress_doc.bbclass`` file.
-   
+
    EFI_PROVIDER
       When building bootable images (i.e. where ``hddimg``, ``iso``, or
       ``wic.vmdk`` is in :term:`IMAGE_FSTYPES`), the
       ``EFI_PROVIDER`` variable specifies the EFI bootloader to use. The
       default is "grub-efi", but "systemd-boot" can be used instead.
-   
+
       See the :ref:`systemd-boot <ref-classes-systemd-boot>` and
       :ref:`image-live <ref-classes-image-live>` classes for more
       information.
-   
+
    ENABLE_BINARY_LOCALE_GENERATION
       Variable that controls which locales for ``glibc`` are generated
       during the build (useful if the target device has 64Mbytes of RAM or
       less).
-   
+
    ERR_REPORT_DIR
       When used with the :ref:`report-error <ref-classes-report-error>`
       class, specifies the path used for storing the debug files created by
-      the `error reporting
-      tool <&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool>`__, which
+      the :ref:`error reporting
+      tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`, which
       allows you to submit build errors you encounter to a central
       database. By default, the value of this variable is
       ``${``\ :term:`LOG_DIR`\ ``}/error-report``.
-   
+
       You can set ``ERR_REPORT_DIR`` to the path you want the error
       reporting tool to store the debug files as follows in your
-      ``local.conf`` file: ERR_REPORT_DIR = "path"
-   
+      ``local.conf`` file:
+      ::
+
+         ERR_REPORT_DIR = "path"
+
    ERROR_QA
       Specifies the quality assurance checks whose failures are reported as
       errors by the OpenEmbedded build system. You set this variable in
       your distribution configuration file. For a list of the checks you
       can control with this variable, see the
       ":ref:`insane.bbclass <ref-classes-insane>`" section.
-   
+
    EXCLUDE_FROM_SHLIBS
       Triggers the OpenEmbedded build system's shared libraries resolver to
       exclude an entire package when scanning for shared libraries.
-   
+
       .. note::
-   
+
          The shared libraries resolver's functionality results in part from
          the internal function
          package_do_shlibs
@@ -1915,25 +2095,28 @@ system and gives an overview of their function and contents.
          do_package
          task. You should be aware that the shared libraries resolver might
          implicitly define some dependencies between packages.
-   
+
       The ``EXCLUDE_FROM_SHLIBS`` variable is similar to the
       :term:`PRIVATE_LIBS` variable, which excludes a
       package's particular libraries only and not the whole package.
-   
+
       Use the ``EXCLUDE_FROM_SHLIBS`` variable by setting it to "1" for a
-      particular package: EXCLUDE_FROM_SHLIBS = "1"
-   
+      particular package:
+      ::
+
+         EXCLUDE_FROM_SHLIBS = "1"
+
    EXCLUDE_FROM_WORLD
       Directs BitBake to exclude a recipe from world builds (i.e.
       ``bitbake world``). During world builds, BitBake locates, parses and
       builds all recipes found in every layer exposed in the
       ``bblayers.conf`` configuration file.
-   
+
       To exclude a recipe from a world build using this variable, set the
       variable to "1" in the recipe.
-   
+
       .. note::
-   
+
          Recipes added to
          EXCLUDE_FROM_WORLD
          may still be built during a world build in order to satisfy
@@ -1941,52 +2124,53 @@ system and gives an overview of their function and contents.
          EXCLUDE_FROM_WORLD
          only ensures that the recipe is not explicitly added to the list
          of build targets in a world build.
-   
+
    EXTENDPE
       Used with file and pathnames to create a prefix for a recipe's
       version based on the recipe's :term:`PE` value. If ``PE``
       is set and greater than zero for a recipe, ``EXTENDPE`` becomes that
-      value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1_").
+      value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1").
       If a recipe's ``PE`` is not set (the default) or is equal to zero,
       ``EXTENDPE`` becomes "".
-   
+
       See the :term:`STAMP` variable for an example.
-   
+
    EXTENDPKGV
       The full package version specification as it appears on the final
       packages produced by a recipe. The variable's value is normally used
       to fix a runtime dependency to the exact same version of another
-      package in the same recipe: RDEPENDS_${PN}-additional-module = "${PN}
-      (= ${EXTENDPKGV})"
-   
+      package in the same recipe:
+      ::
+
+         RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
+
       The dependency relationships are intended to force the package
       manager to upgrade these types of packages in lock-step.
-   
+
    EXTERNAL_KERNEL_TOOLS
       When set, the ``EXTERNAL_KERNEL_TOOLS`` variable indicates that these
       tools are not in the source tree.
-   
+
       When kernel tools are available in the tree, they are preferred over
       any externally installed tools. Setting the ``EXTERNAL_KERNEL_TOOLS``
       variable tells the OpenEmbedded build system to prefer the installed
       external tools. See the
       :ref:`kernel-yocto <ref-classes-kernel-yocto>` class in
       ``meta/classes`` to see how the variable is used.
-   
+
    EXTERNALSRC
       When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
       class, this variable points to the source tree, which is outside of
       the OpenEmbedded build system. When set, this variable sets the
       :term:`S` variable, which is what the OpenEmbedded build
       system uses to locate unpacked recipe source code.
-   
+
       For more information on ``externalsrc.bbclass``, see the
       ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
       can also find information on how to use this variable in the
-      "`Building Software from an External
-      Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    EXTERNALSRC_BUILD
       When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
       class, this variable points to the directory in which the recipe's
@@ -1994,121 +2178,124 @@ system and gives an overview of their function and contents.
       system. When set, this variable sets the :term:`B` variable,
       which is what the OpenEmbedded build system uses to locate the Build
       Directory.
-   
+
       For more information on ``externalsrc.bbclass``, see the
       ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
       can also find information on how to use this variable in the
-      "`Building Software from an External
-      Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    EXTRA_AUTORECONF
       For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
       class, you can use ``EXTRA_AUTORECONF`` to specify extra options to
       pass to the ``autoreconf`` command that is executed during the
       :ref:`ref-tasks-configure` task.
-   
+
       The default value is "--exclude=autopoint".
-   
+
    EXTRA_IMAGE_FEATURES
       A list of additional features to include in an image. When listing
       more than one feature, separate them with a space.
-   
+
       Typically, you configure this variable in your ``local.conf`` file,
       which is found in the :term:`Build Directory`.
       Although you can use this variable from within a recipe, best
       practices dictate that you do not.
-   
+
       .. note::
-   
+
          To enable primary features from within the image recipe, use the
          IMAGE_FEATURES
          variable.
-   
-      Here are some examples of features you can add: "dbg-pkgs" - Adds
-      -dbg packages for all installed packages including symbol information
-      for debugging and profiling. "debug-tweaks" - Makes an image suitable
-      for debugging. For example, allows root logins without passwords and
-      enables post-installation logging. See the 'allow-empty-password' and
-      'post-install-logging' features in the "`Image
-      Features <#ref-features-image>`__" section for more information.
-      "dev-pkgs" - Adds -dev packages for all installed packages. This is
-      useful if you want to develop against the libraries in the image.
-      "read-only-rootfs" - Creates an image whose root filesystem is
-      read-only. See the "`Creating a Read-Only Root
-      Filesystem <&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem>`__"
-      section in the Yocto Project Development Tasks Manual for more
-      information "tools-debug" - Adds debugging tools such as gdb and
-      strace. "tools-sdk" - Adds development tools such as gcc, make,
-      pkgconfig and so forth. "tools-testapps" - Adds useful testing tools
-      such as ts_print, aplay, arecord and so forth.
-   
+
+      Here are some examples of features you can add:
+
+        - "dbg-pkgs" - Adds -dbg packages for all installed packages including
+          symbol information for debugging and profiling.
+
+        - "debug-tweaks" - Makes an image suitable for debugging. For example, allows root logins without passwords and
+          enables post-installation logging. See the 'allow-empty-password' and
+          'post-install-logging' features in the "`Image
+          Features <#ref-features-image>`__" section for more information.
+        - "dev-pkgs" - Adds -dev packages for all installed packages. This is
+          useful if you want to develop against the libraries in the image.
+        - "read-only-rootfs" - Creates an image whose root filesystem is
+          read-only. See the
+          ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
+          section in the Yocto Project Development Tasks Manual for more
+          information
+        - "tools-debug" - Adds debugging tools such as gdb and strace.
+        - "tools-sdk" - Adds development tools such as gcc, make,
+          pkgconfig and so forth.
+        - "tools-testapps" - Adds useful testing tools
+          such as ts_print, aplay, arecord and so forth.
+
       For a complete list of image features that ships with the Yocto
       Project, see the "`Image Features <#ref-features-image>`__" section.
-   
+
       For an example that shows how to customize your image by using this
-      variable, see the "`Customizing Images Using Custom
-      ``IMAGE_FEATURES`` and
-      ``EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures>`__"
+      variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    EXTRA_IMAGECMD
       Specifies additional options for the image creation command that has
       been specified in :term:`IMAGE_CMD`. When setting
       this variable, use an override for the associated image type. Here is
-      an example: EXTRA_IMAGECMD_ext3 ?= "-i 4096"
-   
+      an example:
+      ::
+
+         EXTRA_IMAGECMD_ext3 ?= "-i 4096"
+
    EXTRA_IMAGEDEPENDS
       A list of recipes to build that do not provide packages for
       installing into the root filesystem.
-   
+
       Sometimes a recipe is required to build the final image but is not
       needed in the root filesystem. You can use the ``EXTRA_IMAGEDEPENDS``
       variable to list these recipes and thus specify the dependencies. A
       typical example is a required bootloader in a machine configuration.
-   
+
       .. note::
-   
+
          To add packages to the root filesystem, see the various
-         \*
-         RDEPENDS
-         and
-         \*
-         RRECOMMENDS
+         \*RDEPENDS and \*RRECOMMENDS
          variables.
-   
+
    EXTRANATIVEPATH
       A list of subdirectories of
       ``${``\ :term:`STAGING_BINDIR_NATIVE`\ ``}``
       added to the beginning of the environment variable ``PATH``. As an
       example, the following prepends
       "${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:" to
-      ``PATH``: EXTRANATIVEPATH = "foo bar"
-   
+      ``PATH``:
+      ::
+
+         EXTRANATIVEPATH = "foo bar"
+
    EXTRA_OECMAKE
       Additional `CMake <https://cmake.org/overview/>`__ options. See the
       :ref:`cmake <ref-classes-cmake>` class for additional information.
-   
+
    EXTRA_OECONF
       Additional ``configure`` script options. See
       :term:`PACKAGECONFIG_CONFARGS` for
       additional information on passing configure script options.
-   
+
    EXTRA_OEMAKE
       Additional GNU ``make`` options.
-   
+
       Because the ``EXTRA_OEMAKE`` defaults to "", you need to set the
       variable to specify any required GNU options.
-   
+
       :term:`PARALLEL_MAKE` and
       :term:`PARALLEL_MAKEINST` also make use of
       ``EXTRA_OEMAKE`` to pass the required flags.
-   
+
    EXTRA_OESCONS
       When inheriting the :ref:`scons <ref-classes-scons>` class, this
       variable specifies additional configuration options you want to pass
       to the ``scons`` command line.
-   
+
    EXTRA_USERS_PARAMS
       When inheriting the :ref:`extrausers <ref-classes-extrausers>`
       class, this variable provides image level user and group operations.
@@ -2116,26 +2303,35 @@ system and gives an overview of their function and contents.
       configuration as compared to using the
       :ref:`useradd <ref-classes-useradd>` class, which ties user and
       group configurations to a specific recipe.
-   
+
       The set list of commands you can configure using the
       ``EXTRA_USERS_PARAMS`` is shown in the ``extrausers`` class. These
-      commands map to the normal Unix commands of the same names: #
-      EXTRA_USERS_PARAMS = "\\ # useradd -p '' tester; \\ # groupadd
-      developers; \\ # userdel nobody; \\ # groupdel -g video; \\ #
-      groupmod -g 1020 developers; \\ # usermod -s /bin/sh tester; \\ # "
-   
+      commands map to the normal Unix commands of the same names:
+      ::
+
+         # EXTRA_USERS_PARAMS = "\
+         # useradd -p '' tester; \
+         # groupadd developers; \
+         # userdel nobody; \
+         # groupdel -g video; \
+         # groupmod -g 1020 developers; \
+         # usermod -s /bin/sh tester; \
+         # "
+
    FEATURE_PACKAGES
       Defines one or more packages to include in an image when a specific
       item is included in :term:`IMAGE_FEATURES`.
       When setting the value, ``FEATURE_PACKAGES`` should have the name of
       the feature item as an override. Here is an example:
-      FEATURE_PACKAGES_widget = "package1 package2"
-   
+      ::
+
+         FEATURE_PACKAGES_widget = "package1 package2"
+
       In this example, if "widget" were added to ``IMAGE_FEATURES``,
       package1 and package2 would be included in the image.
-   
+
       .. note::
-   
+
          Packages installed by features defined through
          FEATURE_PACKAGES
          are often package groups. While similarly named, you should not
@@ -2143,40 +2339,46 @@ system and gives an overview of their function and contents.
          FEATURE_PACKAGES
          variable with package groups, which are discussed elsewhere in the
          documentation.
-   
+
    FEED_DEPLOYDIR_BASE_URI
       Points to the base URL of the server and location within the
       document-root that provides the metadata and packages required by
       OPKG to support runtime package management of IPK packages. You set
       this variable in your ``local.conf`` file.
-   
-      Consider the following example: FEED_DEPLOYDIR_BASE_URI =
-      "http://192.168.7.1/BOARD-dir" This example assumes you are serving
+
+      Consider the following example:
+      ::
+
+         FEED_DEPLOYDIR_BASE_URI = "http://192.168.7.1/BOARD-dir"
+
+      This example assumes you are serving
       your packages over HTTP and your databases are located in a directory
       named ``BOARD-dir``, which is underneath your HTTP server's
       document-root. In this case, the OpenEmbedded build system generates
       a set of configuration files for you in your target that work with
       the feed.
-   
+
    FILES
       The list of files and directories that are placed in a package. The
       :term:`PACKAGES` variable lists the packages
       generated by a recipe.
-   
+
       To use the ``FILES`` variable, provide a package name override that
       identifies the resulting package. Then, provide a space-separated
       list of files or paths that identify the files you want included as
-      part of the resulting package. Here is an example: FILES_${PN} +=
-      "${bindir}/mydir1 ${bindir}/mydir2/myfile"
-   
+      part of the resulting package. Here is an example:
+      ::
+
+         FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
+
       .. note::
-   
+
          -  When specifying files or paths, you can pattern match using
             Python's
-            ```glob`https://docs.python.org/2/library/glob.html
+            `glob <https://docs.python.org/3/library/glob.html>`_
             syntax. For details on the syntax, see the documentation by
             following the previous link.
-   
+
          -  When specifying paths as part of the ``FILES`` variable, it is
             good practice to use appropriate path variables. For example,
             use ``${sysconfdir}`` rather than ``/etc``, or ``${bindir}``
@@ -2185,24 +2387,26 @@ system and gives an overview of their function and contents.
             the :term:`Source Directory`. You will also
             find the default values of the various ``FILES_*`` variables in
             this file.
-   
+
       If some of the files you provide with the ``FILES`` variable are
       editable and you know they should not be overwritten during the
       package update process by the Package Management System (PMS), you
       can identify these files so that the PMS will not overwrite them. See
       the :term:`CONFFILES` variable for information on
       how to identify these files to the PMS.
-   
+
    FILES_SOLIBSDEV
       Defines the file specification to match
       :term:`SOLIBSDEV`. In other words,
       ``FILES_SOLIBSDEV`` defines the full path name of the development
       symbolic link (symlink) for shared libraries on the target platform.
-   
+
       The following statement from the ``bitbake.conf`` shows how it is
-      set: FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV}
-      ${libdir}/lib*${SOLIBSDEV}"
-   
+      set:
+      ::
+
+         FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
+
    FILESEXTRAPATHS
       Extends the search path the OpenEmbedded build system uses when
       looking for files and patches as it processes recipes and append
@@ -2210,58 +2414,71 @@ system and gives an overview of their function and contents.
       are initially defined by the :term:`FILESPATH`
       variable. You can extend ``FILESPATH`` variable by using
       ``FILESEXTRAPATHS``.
-   
+
       Best practices dictate that you accomplish this by using
       ``FILESEXTRAPATHS`` from within a ``.bbappend`` file and that you
-      prepend paths as follows: FILESEXTRAPATHS_prepend :=
-      "${THISDIR}/${PN}:" In the above example, the build system first
+      prepend paths as follows:
+      ::
+
+         FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+      In the above example, the build system first
       looks for files in a directory that has the same name as the
       corresponding append file.
-   
+
       .. note::
-   
+
          When extending ``FILESEXTRAPATHS``, be sure to use the immediate
          expansion (``:=``) operator. Immediate expansion makes sure that
          BitBake evaluates :term:`THISDIR` at the time the
          directive is encountered rather than at some later time when
          expansion might result in a directory that does not contain the
          files you need.
-   
+
          Also, include the trailing separating colon character if you are
          prepending. The trailing colon character is necessary because you
          are directing BitBake to extend the path by prepending directories
          to the search path.
-   
-      Here is another common use: FILESEXTRAPATHS_prepend :=
-      "${THISDIR}/files:" In this example, the build system extends the
+
+      Here is another common use:
+      ::
+
+         FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+      In this example, the build system extends the
       ``FILESPATH`` variable to include a directory named ``files`` that is
       in the same directory as the corresponding append file.
-   
+
       This next example specifically adds three paths:
-      FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
-   
+      ::
+
+         FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+
       A final example shows how you can extend the search path and include
       a :term:`MACHINE`-specific override, which is useful
-      in a BSP layer: FILESEXTRAPATHS_prepend_intel-x86-common :=
-      "${THISDIR}/${PN}:" The previous statement appears in the
-      ``linux-yocto-dev.bbappend`` file, which is found in the Yocto
-      Project `Source
-      Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ in
+      in a BSP layer:
+      ::
+
+          FILESEXTRAPATHS_prepend_intel-x86-common := "${THISDIR}/${PN}:"
+
+      The previous statement appears in the
+      ``linux-yocto-dev.bbappend`` file, which is found in the
+      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in
       ``meta-intel/common/recipes-kernel/linux``. Here, the machine
       override is a special :term:`PACKAGE_ARCH`
       definition for multiple ``meta-intel`` machines.
-   
+
       .. note::
-   
+
          For a layer that supports a single BSP, the override could just be
          the value of
          MACHINE
          .
-   
+
       By prepending paths in ``.bbappend`` files, you allow multiple append
       files that reside in different layers but are used for the same
       recipe to correctly extend the path.
-   
+
    FILESOVERRIDES
       A subset of :term:`OVERRIDES` used by the
       OpenEmbedded build system for creating
@@ -2273,53 +2490,63 @@ system and gives an overview of their function and contents.
       are handled in the
       ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`"
       section of the BitBake User Manual.
-   
+
       By default, the ``FILESOVERRIDES`` variable is defined as:
-      FILESOVERRIDES =
-      "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
-   
+      ::
+
+         FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
+
       .. note::
-   
+
          Do not hand-edit the
          FILESOVERRIDES
          variable. The values match up with expected overrides and are used
          in an expected manner by the build system.
-   
+
    FILESPATH
       The default set of directories the OpenEmbedded build system uses
       when searching for patches and files.
-   
+
       During the build process, BitBake searches each directory in
       ``FILESPATH`` in the specified order when looking for files and
       patches specified by each ``file://`` URI in a recipe's
       :term:`SRC_URI` statements.
-   
+
       The default value for the ``FILESPATH`` variable is defined in the
       ``base.bbclass`` class found in ``meta/classes`` in the
-      :term:`Source Directory`: FILESPATH =
-      "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\
-      "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The
+      :term:`Source Directory`:
+      ::
+
+         FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
+             "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
+
+      The
       ``FILESPATH`` variable is automatically extended using the overrides
       from the :term:`FILESOVERRIDES` variable.
-   
+
       .. note::
-   
+
          -  Do not hand-edit the ``FILESPATH`` variable. If you want the
             build system to look in directories other than the defaults,
             extend the ``FILESPATH`` variable by using the
             :term:`FILESEXTRAPATHS` variable.
-   
+
          -  Be aware that the default ``FILESPATH`` directories do not map
             to directories in custom layers where append files
             (``.bbappend``) are used. If you want the build system to find
             patches or files that reside with your append files, you need
             to extend the ``FILESPATH`` variable by using the
             ``FILESEXTRAPATHS`` variable.
-   
+
       You can take advantage of this searching behavior in useful ways. For
       example, consider a case where the following directory structure
       exists for general and machine-specific configurations:
-      files/defconfig files/MACHINEA/defconfig files/MACHINEB/defconfig
+      ::
+
+         files/defconfig
+         files/MACHINEA/defconfig
+         files/MACHINEB/defconfig
+
       Also in the example, the ``SRC_URI`` statement contains
       "file://defconfig". Given this scenario, you can set
       :term:`MACHINE` to "MACHINEA" and cause the build
@@ -2327,37 +2554,37 @@ system and gives an overview of their function and contents.
       "MACHINEB" and the build system uses files from ``files/MACHINEB``.
       Finally, for any machine other than "MACHINEA" and "MACHINEB", the
       build system uses files from ``files/defconfig``.
-   
+
       You can find out more about the patching process in the
-      "`Patching <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__" section
-      in the Yocto Project Overview and Concepts Manual and the "`Patching
-      Code <&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code>`__" section in
+      ":ref:`patching-dev-environment`" section
+      in the Yocto Project Overview and Concepts Manual and the
+      ":ref:`new-recipe-patching-code`" section in
       the Yocto Project Development Tasks Manual. See the
       :ref:`ref-tasks-patch` task as well.
-   
+
    FILESYSTEM_PERMS_TABLES
       Allows you to define your own file permissions settings table as part
       of your configuration for the packaging process. For example, suppose
       you need a consistent set of custom permissions for a set of groups
       and users across an entire work project. It is best to do this in the
       packages themselves but this is not always possible.
-   
+
       By default, the OpenEmbedded build system uses the ``fs-perms.txt``,
       which is located in the ``meta/files`` folder in the :term:`Source Directory`.
       If you create your own file
       permissions setting table, you should place it in your layer or the
       distro's layer.
-   
+
       You define the ``FILESYSTEM_PERMS_TABLES`` variable in the
       ``conf/local.conf`` file, which is found in the :term:`Build Directory`,
       to point to your custom
       ``fs-perms.txt``. You can specify more than a single file permissions
       setting table. The paths you specify to these files must be defined
       within the :term:`BBPATH` variable.
-   
+
       For guidance on how to create your own file permissions settings
       table file, examine the existing ``fs-perms.txt``.
-   
+
    FIT_HASH_ALG
       Specifies the hash algorithm used in creating the FIT Image. For e.g. sha256.
 
@@ -2369,7 +2596,7 @@ system and gives an overview of their function and contents.
       When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
       this variable specifies the runtime dependencies for font packages.
       By default, the ``FONT_EXTRA_RDEPENDS`` is set to "fontconfig-utils".
-   
+
    FONT_PACKAGES
       When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
       this variable identifies packages containing font files that need to
@@ -2377,168 +2604,189 @@ system and gives an overview of their function and contents.
       that fonts are in the recipe's main package (i.e.
       ``${``\ :term:`PN`\ ``}``). Use this variable if fonts you
       need are in a package other than that main package.
-   
+
    FORCE_RO_REMOVE
       Forces the removal of the packages listed in ``ROOTFS_RO_UNNEEDED``
       during the generation of the root filesystem.
-   
+
       Set the variable to "1" to force the removal of these packages.
-   
+
    FULL_OPTIMIZATION
       The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when
       compiling an optimized system. This variable defaults to "-O2 -pipe
       ${DEBUG_FLAGS}".
-   
+
    GCCPIE
       Enables Position Independent Executables (PIE) within the GNU C
       Compiler (GCC). Enabling PIE in the GCC makes Return Oriented
       Programming (ROP) attacks much more difficult to execute.
-   
+
       By default the ``security_flags.inc`` file enables PIE by setting the
-      variable as follows: GCCPIE ?= "--enable-default-pie"
-   
+      variable as follows:
+      ::
+
+         GCCPIE ?= "--enable-default-pie"
+
    GCCVERSION
       Specifies the default version of the GNU C Compiler (GCC) used for
       compilation. By default, ``GCCVERSION`` is set to "8.x" in the
       ``meta/conf/distro/include/tcmode-default.inc`` include file:
-      GCCVERSION ?= "8.%" You can override this value by setting it in a
+      ::
+
+         GCCVERSION ?= "8.%"
+
+      You can override this value by setting it in a
       configuration file such as the ``local.conf``.
-   
+
    GDB
       The minimal command and arguments to run the GNU Debugger.
-   
+
    GITDIR
       The directory in which a local copy of a Git repository is stored
       when it is cloned.
-   
+
    GLIBC_GENERATE_LOCALES
       Specifies the list of GLIBC locales to generate should you not wish
       to generate all LIBC locals, which can be time consuming.
-   
+
       .. note::
-   
+
          If you specifically remove the locale
          en_US.UTF-8
          , you must set
          IMAGE_LINGUAS
          appropriately.
-   
+
       You can set ``GLIBC_GENERATE_LOCALES`` in your ``local.conf`` file.
-      By default, all locales are generated. GLIBC_GENERATE_LOCALES =
-      "en_GB.UTF-8 en_US.UTF-8"
-   
+      By default, all locales are generated.
+      ::
+
+         GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8"
+
    GROUPADD_PARAM
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
       this variable specifies for a package what parameters should be
       passed to the ``groupadd`` command if you wish to add a group to the
       system when the package is installed.
-   
-      Here is an example from the ``dbus`` recipe: GROUPADD_PARAM_${PN} =
-      "-r netdev" For information on the standard Linux shell command
+
+      Here is an example from the ``dbus`` recipe:
+      ::
+
+         GROUPADD_PARAM_${PN} = "-r netdev"
+
+      For information on the standard Linux shell command
       ``groupadd``, see http://linux.die.net/man/8/groupadd.
-   
+
    GROUPMEMS_PARAM
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
       this variable specifies for a package what parameters should be
       passed to the ``groupmems`` command if you wish to modify the members
       of a group when the package is installed.
-   
+
       For information on the standard Linux shell command ``groupmems``,
       see http://linux.die.net/man/8/groupmems.
-   
+
    GRUB_GFXSERIAL
       Configures the GNU GRand Unified Bootloader (GRUB) to have graphics
       and serial in the boot menu. Set this variable to "1" in your
       ``local.conf`` or distribution configuration file to enable graphics
       and serial in the menu.
-   
+
       See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
       information on how this variable is used.
-   
+
    GRUB_OPTS
       Additional options to add to the GNU GRand Unified Bootloader (GRUB)
       configuration. Use a semi-colon character (``;``) to separate
       multiple options.
-   
+
       The ``GRUB_OPTS`` variable is optional. See the
       :ref:`grub-efi <ref-classes-grub-efi>` class for more information
       on how this variable is used.
-   
+
    GRUB_TIMEOUT
       Specifies the timeout before executing the default ``LABEL`` in the
       GNU GRand Unified Bootloader (GRUB).
-   
+
       The ``GRUB_TIMEOUT`` variable is optional. See the
       :ref:`grub-efi <ref-classes-grub-efi>` class for more information
       on how this variable is used.
-   
+
    GTKIMMODULES_PACKAGES
       When inheriting the
       :ref:`gtk-immodules-cache <ref-classes-gtk-immodules-cache>` class,
       this variable specifies the packages that contain the GTK+ input
       method modules being installed when the modules are in packages other
       than the main package.
-   
+
    HOMEPAGE
       Website where more information about the software the recipe is
       building can be found.
-   
+
    HOST_ARCH
       The name of the target architecture, which is normally the same as
       :term:`TARGET_ARCH`. The OpenEmbedded build system
       supports many architectures. Here is an example list of architectures
       supported. This list is by no means complete as the architecture is
-      configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel
-   
+      configurable:
+
+      - arm
+      - i586
+      - x86_64
+      - powerpc
+      - powerpc64
+      - mips
+      - mipsel
+
    HOST_CC_ARCH
       Specifies architecture-specific compiler flags that are passed to the
       C compiler.
-   
+
       Default initialization for ``HOST_CC_ARCH`` varies depending on what
       is being built:
-   
+
       -  :term:`TARGET_CC_ARCH` when building for the
          target
-   
+
       -  ``BUILD_CC_ARCH`` when building for the build host (i.e.
          ``-native``)
-   
+
       -  ``BUILDSDK_CC_ARCH`` when building for an SDK (i.e.
          ``nativesdk-``)
-   
+
    HOST_OS
       Specifies the name of the target operating system, which is normally
       the same as the :term:`TARGET_OS`. The variable can
       be set to "linux" for ``glibc``-based systems and to "linux-musl" for
       ``musl``. For ARM/EABI targets, there are also "linux-gnueabi" and
       "linux-musleabi" values possible.
-   
+
    HOST_PREFIX
       Specifies the prefix for the cross-compile toolchain. ``HOST_PREFIX``
       is normally the same as :term:`TARGET_PREFIX`.
-   
+
    HOST_SYS
       Specifies the system, including the architecture and the operating
       system, for which the build is occurring in the context of the
       current recipe.
-   
+
       The OpenEmbedded build system automatically sets this variable based
       on :term:`HOST_ARCH`,
       :term:`HOST_VENDOR`, and
       :term:`HOST_OS` variables.
-   
+
       .. note::
-   
+
          You do not need to set the variable yourself.
-   
+
       Consider these two examples:
-   
+
       -  Given a native recipe on a 32-bit x86 machine running Linux, the
          value is "i686-linux".
-   
+
       -  Given a recipe being built for a little-endian MIPS target running
          Linux, the value might be "mipsel-linux".
-   
+
    HOSTTOOLS
       A space-separated list (filter) of tools on the build host that
       should be allowed to be called from within build tasks. Using this
@@ -2546,10 +2794,10 @@ system and gives an overview of their function and contents.
       specified in the value of ``HOSTTOOLS`` is not found on the build
       host, the OpenEmbedded build system produces an error and the build
       is not started.
-   
+
       For additional information, see
       :term:`HOSTTOOLS_NONFATAL`.
-   
+
    HOSTTOOLS_NONFATAL
       A space-separated list (filter) of tools on the build host that
       should be allowed to be called from within build tasks. Using this
@@ -2558,44 +2806,51 @@ system and gives an overview of their function and contents.
       does not produce an error if a tool specified in the value of
       ``HOSTTOOLS_NONFATAL`` is not found on the build host. Thus, you can
       use ``HOSTTOOLS_NONFATAL`` to filter optional host tools.
-   
+
    HOST_VENDOR
       Specifies the name of the vendor. ``HOST_VENDOR`` is normally the
       same as :term:`TARGET_VENDOR`.
-   
+
    ICECC_DISABLED
       Disables or enables the ``icecc`` (Icecream) function. For more
       information on this function and best practices for using this
       variable, see the ":ref:`icecc.bbclass <ref-classes-icecc>`"
       section.
-   
+
       Setting this variable to "1" in your ``local.conf`` disables the
-      function: ICECC_DISABLED ??= "1" To enable the function, set the
-      variable as follows: ICECC_DISABLED = ""
-   
+      function:
+      ::
+
+         ICECC_DISABLED ??= "1"
+
+      To enable the function, set the variable as follows:
+      ::
+
+         ICECC_DISABLED = ""
+
    ICECC_ENV_EXEC
       Points to the ``icecc-create-env`` script that you provide. This
       variable is used by the :ref:`icecc <ref-classes-icecc>` class. You
       set this variable in your ``local.conf`` file.
-   
+
       If you do not point to a script that you provide, the OpenEmbedded
       build system uses the default script provided by the
       ``icecc-create-env.bb`` recipe, which is a modified version and not
       the one that comes with ``icecc``.
-   
+
    ICECC_PARALLEL_MAKE
       Extra options passed to the ``make`` command during the
       :ref:`ref-tasks-compile` task that specify parallel
       compilation. This variable usually takes the form of "-j x", where x
       represents the maximum number of parallel threads ``make`` can run.
-   
+
       .. note::
-   
+
          The options passed affect builds on all enabled machines on the
          network, which are machines running the
          iceccd
          daemon.
-   
+
       If your enabled machines support multiple cores, coming up with the
       maximum number of parallel threads that gives you the best
       performance could take some experimentation since machine speed,
@@ -2604,37 +2859,37 @@ system and gives an overview of their function and contents.
       :term:`PARALLEL_MAKE` variable, there is no
       rule-of-thumb for setting ``ICECC_PARALLEL_MAKE`` to achieve optimal
       performance.
-   
+
       If you do not set ``ICECC_PARALLEL_MAKE``, the build system does not
       use it (i.e. the system does not detect and assign the number of
       cores as is done with ``PARALLEL_MAKE``).
-   
+
    ICECC_PATH
       The location of the ``icecc`` binary. You can set this variable in
       your ``local.conf`` file. If your ``local.conf`` file does not define
       this variable, the :ref:`icecc <ref-classes-icecc>` class attempts
       to define it by locating ``icecc`` using ``which``.
-   
+
    ICECC_USER_CLASS_BL
       Identifies user classes that you do not want the Icecream distributed
       compile support to consider. This variable is used by the
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
       your ``local.conf`` file.
-   
+
       When you list classes using this variable, you are "blacklisting"
       them from distributed compilation across remote hosts. Any classes
       you list will be distributed and compiled locally.
-   
+
    ICECC_USER_PACKAGE_BL
       Identifies user recipes that you do not want the Icecream distributed
       compile support to consider. This variable is used by the
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
       your ``local.conf`` file.
-   
+
       When you list packages using this variable, you are "blacklisting"
       them from distributed compilation across remote hosts. Any packages
       you list will be distributed and compiled locally.
-   
+
    ICECC_USER_PACKAGE_WL
       Identifies user recipes that use an empty
       :term:`PARALLEL_MAKE` variable that you want to
@@ -2642,67 +2897,76 @@ system and gives an overview of their function and contents.
       distributed compile support. This variable is used by the
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
       your ``local.conf`` file.
-   
+
    IMAGE_BASENAME
       The base name of image output files. This variable defaults to the
       recipe name (``${``\ :term:`PN`\ ``}``).
-   
+
    IMAGE_BOOT_FILES
       A space-separated list of files installed into the boot partition
       when preparing an image using the Wic tool with the
-      ``bootimg-partition`` or ``bootimg-efi`` source plugin. By default, 
+      ``bootimg-partition`` or ``bootimg-efi`` source plugin. By default,
       the files are
       installed under the same name as the source files. To change the
       installed name, separate it from the original name with a semi-colon
       (;). Source files need to be located in
       :term:`DEPLOY_DIR_IMAGE`. Here are two
-      examples: IMAGE_BOOT_FILES = "u-boot.img uImage;kernel"
-      IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}"
-   
+      examples:
+      ::
+
+         IMAGE_BOOT_FILES = "u-boot.img uImage;kernel"
+         IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}"
+
       Alternatively, source files can be picked up using a glob pattern. In
       this case, the destination file must have the same name as the base
       name of the source file path. To install files into a directory
       within the target location, pass its name after a semi-colon (;).
-      Here are two examples: IMAGE_BOOT_FILES = "bcm2835-bootfiles/*"
-      IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/" The first example
+      Here are two examples:
+      ::
+
+         IMAGE_BOOT_FILES = "bcm2835-bootfiles/*"
+         IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/"
+
+      The first example
       installs all files from ``${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles``
       into the root of the target partition. The second example installs
       the same files into a ``boot`` directory within the target partition.
-   
-      You can find information on how to use the Wic tool in the "`Creating
-      Partitioned Images Using
-      Wic <&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic>`__"
+
+      You can find information on how to use the Wic tool in the
+      ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
       section of the Yocto Project Development Tasks Manual. Reference
-      material for Wic is located in the "`OpenEmbedded Kickstart (.wks)
-      Reference <&YOCTO_DOCS_REF_URL;#ref-kickstart>`__" chapter.
-   
+      material for Wic is located in the
+      ":doc:`../ref-manual/ref-kickstart`" chapter.
+
    IMAGE_CLASSES
       A list of classes that all images should inherit. You typically use
       this variable to specify the list of classes that register the
       different types of images the OpenEmbedded build system creates.
-   
+
       The default value for ``IMAGE_CLASSES`` is ``image_types``. You can
       set this variable in your ``local.conf`` or in a distribution
       configuration file.
-   
+
       For more information, see ``meta/classes/image_types.bbclass`` in the
       :term:`Source Directory`.
-   
+
    IMAGE_CMD
       Specifies the command to create the image file for a specific image
       type, which corresponds to the value set set in
       :term:`IMAGE_FSTYPES`, (e.g. ``ext3``,
       ``btrfs``, and so forth). When setting this variable, you should use
       an override for the associated type. Here is an example:
-      IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \\ --faketime
-      --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \\
-      ${EXTRA_IMAGECMD}"
-   
+      ::
+
+         IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \
+             --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \
+             ${EXTRA_IMAGECMD}"
+
       You typically do not need to set this variable unless you are adding
       support for a new image type. For more examples on how to set this
       variable, see the :ref:`image_types <ref-classes-image_types>`
       class file, which is ``meta/classes/image_types.bbclass``.
-   
+
    IMAGE_DEVICE_TABLES
       Specifies one or more files that contain custom device tables that
       are passed to the ``makedevs`` command as part of creating an image.
@@ -2712,55 +2976,55 @@ system and gives an overview of their function and contents.
       :term:`BBPATH`. For details on how you should write
       device table files, see ``meta/files/device_table-minimal.txt`` as an
       example.
-   
+
    IMAGE_FEATURES
       The primary list of features to include in an image. Typically, you
       configure this variable in an image recipe. Although you can use this
       variable from your ``local.conf`` file, which is found in the
       :term:`Build Directory`, best practices dictate that you do
       not.
-   
+
       .. note::
-   
+
          To enable extra features from outside the image recipe, use the
          EXTRA_IMAGE_FEATURES
          variable.
-   
+
       For a list of image features that ships with the Yocto Project, see
       the "`Image Features <#ref-features-image>`__" section.
-   
+
       For an example that shows how to customize your image by using this
-      variable, see the "`Customizing Images Using Custom
-      ``IMAGE_FEATURES`` and
-      ``EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures>`__"
+      variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    IMAGE_FSTYPES
       Specifies the formats the OpenEmbedded build system uses during the
       build when creating the root filesystem. For example, setting
       ``IMAGE_FSTYPES`` as follows causes the build system to create root
       filesystems using two formats: ``.ext3`` and ``.tar.bz2``:
-      IMAGE_FSTYPES = "ext3 tar.bz2"
-   
+      ::
+
+         IMAGE_FSTYPES = "ext3 tar.bz2"
+
       For the complete list of supported image formats from which you can
       choose, see :term:`IMAGE_TYPES`.
-   
+
       .. note::
-   
+
          -  If an image recipe uses the "inherit image" line and you are
             setting ``IMAGE_FSTYPES`` inside the recipe, you must set
             ``IMAGE_FSTYPES`` prior to using the "inherit image" line.
-   
+
          -  Due to the way the OpenEmbedded build system processes this
             variable, you cannot update its contents by using ``_append``
             or ``_prepend``. You must use the ``+=`` operator to add one or
             more options to the ``IMAGE_FSTYPES`` variable.
-   
+
    IMAGE_INSTALL
       Used by recipes to specify the packages to install into an image
       through the :ref:`image <ref-classes-image>` class. Use the
       ``IMAGE_INSTALL`` variable with care to avoid ordering issues.
-   
+
       Image recipes set ``IMAGE_INSTALL`` to specify the packages to
       install into an image through ``image.bbclass``. Additionally,
       "helper" classes such as the
@@ -2768,14 +3032,18 @@ system and gives an overview of their function and contents.
       take lists used with ``IMAGE_FEATURES`` and turn them into
       auto-generated entries in ``IMAGE_INSTALL`` in addition to its
       default contents.
-   
+
       When you use this variable, it is best to use it as follows:
-      IMAGE_INSTALL_append = " package-name" Be sure to include the space
+      ::
+
+         IMAGE_INSTALL_append = " package-name"
+
+      Be sure to include the space
       between the quotation character and the start of the package name or
       names.
-   
+
       .. note::
-   
+
          -  When working with a
             ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__
             image, do not use the ``IMAGE_INSTALL`` variable to specify
@@ -2783,11 +3051,10 @@ system and gives an overview of their function and contents.
             :term:`PACKAGE_INSTALL` variable, which
             allows the initial RAM filesystem (initramfs) recipe to use a
             fixed set of packages and not be affected by ``IMAGE_INSTALL``.
-            For information on creating an initramfs, see the "`Building an
-            Initial RAM Filesystem (initramfs)
-            Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__"
+            For information on creating an initramfs, see the
+            ":ref:`building-an-initramfs-image`"
             section in the Yocto Project Development Tasks Manual.
-   
+
          -  Using ``IMAGE_INSTALL`` with the
             :ref:`+= <bitbake:appending-and-prepending>`
             BitBake operator within the ``/conf/local.conf`` file or from
@@ -2802,7 +3069,7 @@ system and gives an overview of their function and contents.
             within an image recipe may or may not succeed depending on the
             specific situation. In both these cases, the behavior is
             contrary to how most users expect the ``+=`` operator to work.
-   
+
    IMAGE_LINGUAS
       Specifies the list of locales to install into the image during the
       root filesystem construction process. The OpenEmbedded build system
@@ -2810,39 +3077,50 @@ system and gives an overview of their function and contents.
       into separate packages. Setting the ``IMAGE_LINGUAS`` variable
       ensures that any locale packages that correspond to packages already
       selected for installation into the image are also installed. Here is
-      an example: IMAGE_LINGUAS = "pt-br de-de"
-   
+      an example:
+      ::
+
+         IMAGE_LINGUAS = "pt-br de-de"
+
       In this example, the build system ensures any Brazilian Portuguese
       and German locale files that correspond to packages in the image are
       installed (i.e. ``*-locale-pt-br`` and ``*-locale-de-de`` as well as
       ``*-locale-pt`` and ``*-locale-de``, since some software packages
       only provide locale files by language and not by country-specific
       language).
-   
+
       See the :term:`GLIBC_GENERATE_LOCALES`
       variable for information on generating GLIBC locales.
-   
+
    IMAGE_MANIFEST
       The manifest file for the image. This file lists all the installed
       packages that make up the image. The file contains package
-      information on a line-per-package basis as follows: packagename
-      packagearch version
-   
+      information on a line-per-package basis as follows:
+      ::
+
+          packagename packagearch version
+
       The :ref:`image <ref-classes-image>` class defines the manifest
-      file as follows: IMAGE_MANIFEST =
-      "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest" The location is
+      file as follows:
+      ::
+
+         IMAGE_MANIFEST ="${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest"
+
+      The location is
       derived using the :term:`DEPLOY_DIR_IMAGE`
       and :term:`IMAGE_NAME` variables. You can find
-      information on how the image is created in the "`Image
-      Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__"
+      information on how the image is created in the ":ref:`image-generation-dev-environment`"
       section in the Yocto Project Overview and Concepts Manual.
-   
+
    IMAGE_NAME
       The name of the output image files minus the extension. This variable
       is derived using the :term:`IMAGE_BASENAME`,
       :term:`MACHINE`, and :term:`DATETIME`
-      variables: IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
-   
+      variables:
+      ::
+
+         IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
+
    IMAGE_OVERHEAD_FACTOR
       Defines a multiplier that the build system applies to the initial
       image size for cases when the multiplier times the returned disk
@@ -2858,18 +3136,20 @@ system and gives an overview of their function and contents.
       not produce an image with all the theoretical free disk space. See
       ``IMAGE_ROOTFS_SIZE`` for information on how the build system
       determines the overall image size.
-   
+
       The default 30% free disk space typically gives the image enough room
       to boot and allows for basic post installs while still leaving a
       small amount of free disk space. If 30% free space is inadequate, you
       can increase the default value. For example, the following setting
-      gives you 50% free space added to the image: IMAGE_OVERHEAD_FACTOR =
-      "1.5"
-   
+      gives you 50% free space added to the image:
+      ::
+
+         IMAGE_OVERHEAD_FACTOR = "1.5"
+
       Alternatively, you can ensure a specific amount of free disk space is
       added to the image by using the ``IMAGE_ROOTFS_EXTRA_SPACE``
       variable.
-   
+
    IMAGE_PKGTYPE
       Defines the package type (i.e. DEB, RPM, IPK, or TAR) used by the
       OpenEmbedded build system. The variable is defined appropriately by
@@ -2877,84 +3157,92 @@ system and gives an overview of their function and contents.
       :ref:`package_rpm <ref-classes-package_rpm>`,
       :ref:`package_ipk <ref-classes-package_ipk>`, or
       :ref:`package_tar <ref-classes-package_tar>` class.
-   
+
       .. note::
-   
+
          The
          package_tar
          class is broken and is not supported. It is recommended that you
          do not use it.
-   
+
       The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` and
       :ref:`image <ref-classes-image>` classes use the ``IMAGE_PKGTYPE``
       for packaging up images and SDKs.
-   
+
       You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the
       variable is set indirectly through the appropriate
       :ref:`package_* <ref-classes-package>` class using the
       :term:`PACKAGE_CLASSES` variable. The
       OpenEmbedded build system uses the first package type (e.g. DEB, RPM,
       or IPK) that appears with the variable
-   
+
       .. note::
-   
+
          Files using the
          .tar
          format are never used as a substitute packaging format for DEB,
          RPM, and IPK formatted files for your image or SDK.
-   
+
    IMAGE_POSTPROCESS_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system creates the final image output files. You can specify
-      functions separated by semicolons: IMAGE_POSTPROCESS_COMMAND +=
-      "function; ... "
-   
+      functions separated by semicolons:
+      ::
+
+         IMAGE_POSTPROCESS_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within the
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    IMAGE_PREPROCESS_COMMAND
       Specifies a list of functions to call before the OpenEmbedded build
       system creates the final image output files. You can specify
-      functions separated by semicolons: IMAGE_PREPROCESS_COMMAND +=
-      "function; ... "
-   
+      functions separated by semicolons:
+      ::
+
+         IMAGE_PREPROCESS_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within the
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    IMAGE_ROOTFS
       The location of the root filesystem while it is under construction
       (i.e. during the :ref:`ref-tasks-rootfs` task). This
       variable is not configurable. Do not change it.
-   
+
    IMAGE_ROOTFS_ALIGNMENT
       Specifies the alignment for the output image file in Kbytes. If the
       size of the image is not a multiple of this value, then the size is
       rounded up to the nearest multiple of the value. The default value is
       "1". See :term:`IMAGE_ROOTFS_SIZE` for
       additional information.
-   
+
    IMAGE_ROOTFS_EXTRA_SPACE
       Defines additional free disk space created in the image in Kbytes. By
       default, this variable is set to "0". This free disk space is added
       to the image after the build system determines the image size as
       described in ``IMAGE_ROOTFS_SIZE``.
-   
+
       This variable is particularly useful when you want to ensure that a
       specific amount of free disk space is available on a device after an
       image is installed and running. For example, to be sure 5 Gbytes of
       free disk space is available, set the variable as follows:
-      IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
-   
+      ::
+
+         IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
+
       For example, the Yocto Project Build Appliance specifically requests
-      40 Gbytes of extra space with the line: IMAGE_ROOTFS_EXTRA_SPACE =
-      "41943040"
-   
+      40 Gbytes of extra space with the line:
+      ::
+
+         IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
+
    IMAGE_ROOTFS_SIZE
       Defines the size in Kbytes for the generated image. The OpenEmbedded
       build system determines the final size for the generated image using
@@ -2962,45 +3250,87 @@ system and gives an overview of their function and contents.
       the generated image, a requested size for the image, and requested
       additional free disk space to be added to the image. Programatically,
       the build system determines the final size of the generated image as
-      follows: if (image-du \* overhead) < rootfs-size:
-      internal-rootfs-size = rootfs-size + xspace else:
-      internal-rootfs-size = (image-du \* overhead) + xspace where:
-      image-du = Returned value of the du command on the image. overhead =
-      IMAGE_OVERHEAD_FACTOR rootfs-size = IMAGE_ROOTFS_SIZE
-      internal-rootfs-size = Initial root filesystem size before any
-      modifications. xspace = IMAGE_ROOTFS_EXTRA_SPACE
-   
+      follows:
+      ::
+
+         if (image-du * overhead) < rootfs-size:
+             internal-rootfs-size = rootfs-size + xspace
+         else:
+             internal-rootfs-size = (image-du * overhead) + xspace
+         where:
+             image-du = Returned value of the du command on the image.
+             overhead = IMAGE_OVERHEAD_FACTOR
+             rootfs-size = IMAGE_ROOTFS_SIZE
+             internal-rootfs-size = Initial root filesystem size before any modifications.
+             xspace = IMAGE_ROOTFS_EXTRA_SPACE
+
       See the :term:`IMAGE_OVERHEAD_FACTOR`
       and :term:`IMAGE_ROOTFS_EXTRA_SPACE`
       variables for related information.
-   
+
    IMAGE_TYPEDEP
       Specifies a dependency from one image type on another. Here is an
       example from the :ref:`image-live <ref-classes-image-live>` class:
-      IMAGE_TYPEDEP_live = "ext3"
-   
+      ::
+
+         IMAGE_TYPEDEP_live = "ext3"
+
       In the previous example, the variable ensures that when "live" is
       listed with the :term:`IMAGE_FSTYPES` variable,
       the OpenEmbedded build system produces an ``ext3`` image first since
       one of the components of the live image is an ``ext3`` formatted
       partition containing the root filesystem.
-   
+
    IMAGE_TYPES
       Specifies the complete list of supported image types by default:
-      btrfs container cpio cpio.gz cpio.lz4 cpio.lzma cpio.xz cramfs ext2
-      ext2.bz2 ext2.gz ext2.lzma ext3 ext3.gz ext4 ext4.gz f2fs hddimg iso
-      jffs2 jffs2.sum multiubi squashfs squashfs-lz4 squashfs-lzo
-      squashfs-xz tar tar.bz2 tar.gz tar.lz4 tar.xz tar.zst ubi ubifs wic
-      wic.bz2 wic.gz wic.lzma
-   
+
+      - btrfs
+      - container
+      - cpio
+      - cpio.gz
+      - cpio.lz4
+      - cpio.lzma
+      - cpio.xz
+      - cramfs
+      - ext2
+      - ext2.bz2
+      - ext2.gz
+      - ext2.lzma
+      - ext3
+      - ext3.gz
+      - ext4
+      - ext4.gz
+      - f2fs
+      - hddimg
+      - iso
+      - jffs2
+      - jffs2.sum
+      - multiubi
+      - squashfs
+      - squashfs-lz4
+      - squashfs-lzo
+      - squashfs-xz
+      - tar
+      - tar.bz2
+      - tar.gz
+      - tar.lz4
+      - tar.xz
+      - tar.zst
+      - ubi
+      - ubifs
+      - wic
+      - wic.bz2
+      - wic.gz
+      - wic.lzma
+
       For more information about these types of images, see
       ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
-   
+
    INC_PR
       Helps define the recipe revision for recipes that share a common
       ``include`` file. You can think of this variable as part of the
       recipe revision as set from within an include file.
-   
+
       Suppose, for example, you have a set of recipes that are used across
       several projects. And, within each of those recipes the revision (its
       :term:`PR` value) is set accordingly. In this case, when
@@ -3009,49 +3339,53 @@ system and gives an overview of their function and contents.
       updated version of the recipe. In this scenario, it can get
       complicated when recipes that are used in many places and provide
       common functionality are upgraded to a new revision.
-   
+
       A more efficient way of dealing with this situation is to set the
       ``INC_PR`` variable inside the ``include`` files that the recipes
       share and then expand the ``INC_PR`` variable within the recipes to
       help define the recipe revision.
-   
+
       The following provides an example that shows how to use the
       ``INC_PR`` variable given a common ``include`` file that defines the
       variable. Once the variable is defined in the ``include`` file, you
       can use the variable to set the ``PR`` values in each recipe. You
       will notice that when you set a recipe's ``PR`` you can provide more
       granular revisioning by appending values to the ``INC_PR`` variable:
-      recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
-      recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
-      recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
-      recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" The
+      ::
+
+         recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
+         recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
+         recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
+         recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
+
+      The
       first line of the example establishes the baseline revision to be
       used for all recipes that use the ``include`` file. The remaining
       lines in the example are from individual recipes and show how the
       ``PR`` value is set.
-   
+
    INCOMPATIBLE_LICENSE
       Specifies a space-separated list of license names (as they would
       appear in :term:`LICENSE`) that should be excluded
       from the build. Recipes that provide no alternatives to listed
       incompatible licenses are not built. Packages that are individually
       licensed with the specified incompatible licenses will be deleted.
-   
+
       .. note::
-   
+
          This functionality is only regularly tested using the following
          setting:
          ::
-   
+
                  INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
-                                
-   
+
+
          Although you can use other settings, you might be required to
          remove dependencies on or provide alternatives to components that
          are required to produce a functional system image.
-   
+
       .. note::
-   
+
          It is possible to define a list of licenses that are allowed to be
          used instead of the licenses that are excluded. To do this, define
          a variable
@@ -3060,10 +3394,10 @@ system and gives an overview of their function and contents.
          INCOMPATIBLE_LICENSE
          as:
          ::
-   
+
                  INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}"
-                                
-   
+
+
          This will result in
          INCOMPATIBLE_LICENSE
          containing the names of all licences from
@@ -3071,34 +3405,36 @@ system and gives an overview of their function and contents.
          except the ones specified in
          COMPATIBLE_LICENSES
          , thus only allowing the latter licences to be used.
-   
+
    INHERIT
       Causes the named class or classes to be inherited globally. Anonymous
       functions in the class or classes are not executed for the base
       configuration and in each individual recipe. The OpenEmbedded build
       system ignores changes to ``INHERIT`` in individual recipes.
-   
+
       For more information on ``INHERIT``, see the
       :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
       section in the Bitbake User Manual.
-   
+
    INHERIT_DISTRO
       Lists classes that will be inherited at the distribution level. It is
       unlikely that you want to edit this variable.
-   
+
       The default value of the variable is set as follows in the
-      ``meta/conf/distro/defaultsetup.conf`` file: INHERIT_DISTRO ?=
-      "debian devshell sstate license"
-   
+      ``meta/conf/distro/defaultsetup.conf`` file:
+      ::
+
+         INHERIT_DISTRO ?= "debian devshell sstate license"
+
    INHIBIT_DEFAULT_DEPS
       Prevents the default dependencies, namely the C compiler and standard
       C library (libc), from being added to :term:`DEPENDS`.
       This variable is usually used within recipes that do not require any
       compilation using the C compiler.
-   
+
       Set the variable to "1" to prevent the default dependencies from
       being added.
-   
+
    INHIBIT_PACKAGE_DEBUG_SPLIT
       Prevents the OpenEmbedded build system from splitting out debug
       information during packaging. By default, the build system splits out
@@ -3107,37 +3443,40 @@ system and gives an overview of their function and contents.
       how debug information is split out, see the
       :term:`PACKAGE_DEBUG_SPLIT_STYLE`
       variable.
-   
+
       To prevent the build system from splitting out debug information
       during packaging, set the ``INHIBIT_PACKAGE_DEBUG_SPLIT`` variable as
-      follows: INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
-   
+      follows:
+      ::
+
+         INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+
    INHIBIT_PACKAGE_STRIP
       If set to "1", causes the build to not strip binaries in resulting
       packages and prevents the ``-dbg`` package from containing the source
       files.
-   
+
       By default, the OpenEmbedded build system strips binaries and puts
       the debugging symbols into ``${``\ :term:`PN`\ ``}-dbg``.
       Consequently, you should not set ``INHIBIT_PACKAGE_STRIP`` when you
       plan to debug in general.
-   
+
    INHIBIT_SYSROOT_STRIP
       If set to "1", causes the build to not strip binaries in the
       resulting sysroot.
-   
+
       By default, the OpenEmbedded build system strips binaries in the
       resulting sysroot. When you specifically set the
       ``INHIBIT_SYSROOT_STRIP`` variable to "1" in your recipe, you inhibit
       this stripping.
-   
+
       If you want to use this variable, include the
       :ref:`staging <ref-classes-staging>` class. This class uses a
       ``sys_strip()`` function to test for the variable and acts
       accordingly.
-   
+
       .. note::
-   
+
          Use of the
          INHIBIT_SYSROOT_STRIP
          variable occurs in rare and special circumstances. For example,
@@ -3145,20 +3484,20 @@ system and gives an overview of their function and contents.
          GCC toolchain. Furthermore, even if the toolchain's binaries are
          strippable, other files exist that are needed for the build that
          are not strippable.
-   
+
    INITRAMFS_FSTYPES
       Defines the format for the output image of an initial RAM filesystem
       (initramfs), which is used during boot. Supported formats are the
       same as those supported by the
       :term:`IMAGE_FSTYPES` variable.
-   
+
       The default value of this variable, which is set in the
       ``meta/conf/bitbake.conf`` configuration file in the
       :term:`Source Directory`, is "cpio.gz". The Linux kernel's
       initramfs mechanism, as opposed to the initial RAM filesystem
       `initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects
       an optionally compressed cpio archive.
-   
+
    INITRAMFS_IMAGE
       Specifies the :term:`PROVIDES` name of an image
       recipe that is used to build an initial RAM filesystem (initramfs)
@@ -3168,13 +3507,13 @@ system and gives an overview of their function and contents.
       initramfs image recipe you provide should set
       :term:`IMAGE_FSTYPES` to
       :term:`INITRAMFS_FSTYPES`.
-   
+
       An initramfs image provides a temporary root filesystem used for
       early system initialization (e.g. loading of modules needed to locate
       and mount the "real" root filesystem).
-   
+
       .. note::
-   
+
          See the
          meta/recipes-core/images/core-image-minimal-initramfs.bb
          recipe in the
@@ -3183,24 +3522,23 @@ system and gives an overview of their function and contents.
          the one built to provide the initramfs image, set
          INITRAMFS_IMAGE
          to "core-image-minimal-initramfs".
-   
+
       You can also find more information by referencing the
       ``meta-poky/conf/local.conf.sample.extended`` configuration file in
       the Source Directory, the :ref:`image <ref-classes-image>` class,
       and the :ref:`kernel <ref-classes-kernel>` class to see how to use
       the ``INITRAMFS_IMAGE`` variable.
-   
+
       If ``INITRAMFS_IMAGE`` is empty, which is the default, then no
       initramfs image is built.
-   
+
       For more information, you can also see the
       :term:`INITRAMFS_IMAGE_BUNDLE`
       variable, which allows the generated image to be bundled inside the
       kernel image. Additionally, for information on creating an initramfs
-      image, see the "`Building an Initial RAM Filesystem (initramfs)
-      Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section
+      image, see the ":ref:`building-an-initramfs-image`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    INITRAMFS_IMAGE_BUNDLE
       Controls whether or not the image recipe specified by
       :term:`INITRAMFS_IMAGE` is run through an
@@ -3211,152 +3549,181 @@ system and gives an overview of their function and contents.
       image. This makes use of the
       :term:`CONFIG_INITRAMFS_SOURCE` kernel
       feature.
-   
+
       .. note::
-   
+
          Using an extra compilation pass to bundle the initramfs avoids a
          circular dependency between the kernel recipe and the initramfs
          recipe should the initramfs include kernel modules. Should that be
          the case, the initramfs recipe depends on the kernel for the
          kernel modules, and the kernel depends on the initramfs recipe
          since the initramfs is bundled inside the kernel image.
-   
+
       The combined binary is deposited into the ``tmp/deploy`` directory,
       which is part of the :term:`Build Directory`.
-   
+
       Setting the variable to "1" in a configuration file causes the
       OpenEmbedded build system to generate a kernel image with the
       initramfs specified in ``INITRAMFS_IMAGE`` bundled within:
-      INITRAMFS_IMAGE_BUNDLE = "1" By default, the
+      ::
+
+         INITRAMFS_IMAGE_BUNDLE = "1"
+
+      By default, the
       :ref:`kernel <ref-classes-kernel>` class sets this variable to a
-      null string as follows: INITRAMFS_IMAGE_BUNDLE ?= ""
-   
+      null string as follows:
+      ::
+
+         INITRAMFS_IMAGE_BUNDLE ?= ""
+
       .. note::
-   
+
          You must set the
          INITRAMFS_IMAGE_BUNDLE
          variable in a configuration file. You cannot set the variable in a
          recipe file.
-   
+
       See the
       :yocto_git:`local.conf.sample.extended </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended>`
       file for additional information. Also, for information on creating an
-      initramfs, see the "`Building an Initial RAM Filesystem (initramfs)
-      Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section
+      initramfs, see the ":ref:`building-an-initramfs-image`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    INITRAMFS_LINK_NAME
       The link name of the initial RAM filesystem image. This variable is
       set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
-      follows: INITRAMFS_LINK_NAME ?=
-      "initramfs-${KERNEL_ARTIFACT_LINK_NAME}" The value of the
+      follows:
+      ::
+
+         INITRAMFS_LINK_NAME ?= "initramfs-${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The value of the
       ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
-      file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
+      file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
       See the :term:`MACHINE` variable for additional
       information.
-   
+
    INITRAMFS_NAME
       The base name of the initial RAM filesystem image. This variable is
       set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
-      follows: INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}" The
-      value of the :term:`KERNEL_ARTIFACT_NAME`
+      follows:
+      ::
+
+         INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}"
+
+      The value of the :term:`KERNEL_ARTIFACT_NAME`
       variable, which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    INITRD
       Indicates list of filesystem images to concatenate and use as an
       initial RAM disk (``initrd``).
-   
+
       The ``INITRD`` variable is an optional variable used with the
       :ref:`image-live <ref-classes-image-live>` class.
-   
+
    INITRD_IMAGE
       When building a "live" bootable image (i.e. when
       :term:`IMAGE_FSTYPES` contains "live"),
       ``INITRD_IMAGE`` specifies the image recipe that should be built to
       provide the initial RAM disk image. The default value is
       "core-image-minimal-initramfs".
-   
+
       See the :ref:`image-live <ref-classes-image-live>` class for more
       information.
-   
+
    INITSCRIPT_NAME
       The filename of the initialization script as installed to
       ``${sysconfdir}/init.d``.
-   
+
       This variable is used in recipes when using ``update-rc.d.bbclass``.
       The variable is mandatory.
-   
+
    INITSCRIPT_PACKAGES
       A list of the packages that contain initscripts. If multiple packages
       are specified, you need to append the package name to the other
       ``INITSCRIPT_*`` as an override.
-   
+
       This variable is used in recipes when using ``update-rc.d.bbclass``.
       The variable is optional and defaults to the :term:`PN`
       variable.
-   
+
    INITSCRIPT_PARAMS
       Specifies the options to pass to ``update-rc.d``. Here is an example:
-      INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
-   
+      ::
+
+         INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
+
       In this example, the script has a runlevel of 99, starts the script
       in initlevels 2 and 5, and stops the script in levels 0, 1 and 6.
-   
+
       The variable's default value is "defaults", which is set in the
       :ref:`update-rc.d <ref-classes-update-rc.d>` class.
-   
+
       The value in ``INITSCRIPT_PARAMS`` is passed through to the
       ``update-rc.d`` command. For more information on valid parameters,
       please see the ``update-rc.d`` manual page at
       http://www.tin.org/bin/man.cgi?section=8&topic=update-rc.d.
-   
+
    INSANE_SKIP
       Specifies the QA checks to skip for a specific package within a
       recipe. For example, to skip the check for symbolic link ``.so``
       files in the main package of a recipe, add the following to the
       recipe. The package name override must be used, which in this example
-      is ``${PN}``: INSANE_SKIP_${PN} += "dev-so"
-   
+      is ``${PN}``:
+      ::
+
+         INSANE_SKIP_${PN} += "dev-so"
+
       See the ":ref:`insane.bbclass <ref-classes-insane>`" section for a
       list of the valid QA checks you can specify using this variable.
-   
+
    INSTALL_TIMEZONE_FILE
       By default, the ``tzdata`` recipe packages an ``/etc/timezone`` file.
       Set the ``INSTALL_TIMEZONE_FILE`` variable to "0" at the
       configuration level to disable this behavior.
-   
+
    IPK_FEED_URIS
       When the IPK backend is in use and package management is enabled on
       the target, you can use this variable to set up ``opkg`` in the
       target image to point to package feeds on a nominated server. Once
       the feed is established, you can perform installations or upgrades
       using the package manager at runtime.
-   
+
    KARCH
       Defines the kernel architecture used when assembling the
-      configuration. Architectures supported for this release are: powerpc
-      i386 x86_64 arm qemu mips
-   
-      You define the ``KARCH`` variable in the `BSP
-      Descriptions <&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions>`__.
-   
+      configuration. Architectures supported for this release are:
+
+      - powerpc
+      - i386
+      - x86_64
+      - arm
+      - qemu
+      - mips
+
+      You define the ``KARCH`` variable in the :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`.
+
    KBRANCH
       A regular expression used by the build process to explicitly identify
       the kernel branch that is validated, patched, and configured during a
       build. You must set this variable to ensure the exact kernel branch
       you want is being used by the build process.
-   
+
       Values for this variable are set in the kernel's recipe file and the
       kernel's append file. For example, if you are using the
       ``linux-yocto_4.12`` kernel, the kernel recipe file is the
       ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` file. ``KBRANCH``
-      is set as follows in that kernel recipe file: KBRANCH ?=
-      "standard/base"
-   
+      is set as follows in that kernel recipe file:
+      ::
+
+         KBRANCH ?= "standard/base"
+
       This variable is also used from the kernel's append file to identify
       the kernel branch specific to a particular machine or target
       hardware. Continuing with the previous kernel example, the kernel's
@@ -3366,17 +3733,22 @@ system and gives an overview of their function and contents.
       machines (``meta-yocto-bsp``) is named
       ``meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend``.
       Here are the related statements from that append file:
-      KBRANCH_genericx86 = "standard/base" KBRANCH_genericx86-64 =
-      "standard/base" KBRANCH_edgerouter = "standard/edgerouter"
-      KBRANCH_beaglebone = "standard/beaglebone" The ``KBRANCH`` statements
+      ::
+
+         KBRANCH_genericx86 = "standard/base"
+         KBRANCH_genericx86-64 = "standard/base"
+         KBRANCH_edgerouter = "standard/edgerouter"
+         KBRANCH_beaglebone = "standard/beaglebone"
+
+      The ``KBRANCH`` statements
       identify the kernel branch to use when building for each supported
       BSP.
-   
+
    KBUILD_DEFCONFIG
       When used with the :ref:`kernel-yocto <ref-classes-kernel-yocto>`
       class, specifies an "in-tree" kernel configuration file for use
       during a kernel build.
-   
+
       Typically, when using a ``defconfig`` to configure a kernel during a
       build, you place the file in your layer in the same manner as you
       would place patch files and configuration fragment files (i.e.
@@ -3385,46 +3757,53 @@ system and gives an overview of their function and contents.
       ``KBUILD_DEFCONFIG`` variable and append the
       :term:`KMACHINE` variable to point to the
       ``defconfig`` file.
-   
+
       To use the variable, set it in the append file for your kernel recipe
-      using the following form: KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
+      using the following form:
+      ::
+
+         KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
+
       Here is an example from a "raspberrypi2" ``KMACHINE`` build that uses
       a ``defconfig`` file named "bcm2709_defconfig":
-      KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig" As an
-      alternative, you can use the following within your append file:
-      KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file For more
+      ::
+
+         KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig"
+
+      As an alternative, you can use the following within your append file:
+      ::
+
+         KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file
+
+      For more
       information on how to use the ``KBUILD_DEFCONFIG`` variable, see the
-      "`Using an "In-Tree" ``defconfig``
-      File <&YOCTO_DOCS_KERNEL_DEV_URL;#using-an-in-tree-defconfig-file>`__"
+      ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`"
       section in the Yocto Project Linux Kernel Development Manual.
-   
+
    KERNEL_ALT_IMAGETYPE
       Specifies an alternate kernel image type for creation in addition to
       the kernel image type specified using the
       :term:`KERNEL_IMAGETYPE` variable.
-   
+
    KERNEL_ARTIFACT_NAME
       Specifies the name of all of the build artifacts. You can change the
       name of the artifacts by changing the ``KERNEL_ARTIFACT_NAME``
       variable.
-   
+
       The value of ``KERNEL_ARTIFACT_NAME``, which is set in the
       ``meta/classes/kernel-artifact-names.bbclass`` file, has the
-      following default value: KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
-      See the :term:`PKGE`, :term:`PKGV`,
-      :term:`PKGR`, and :term:`MACHINE`
+      following default value:
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
+      See the :term:`PKGE`, :term:`PKGV`, :term:`PKGR`, and :term:`MACHINE`
       variables for additional information.
-   
+
       .. note::
-   
-         The
-         IMAGE_VERSION_SUFFIX
-         variable is set to
-         DATETIME
-         .
-   
+
+         The IMAGE_VERSION_SUFFIX variable is set to DATETIME.
+
    KERNEL_CLASSES
       A list of classes defining kernel image types that the
       :ref:`kernel <ref-classes-kernel>` class should inherit. You
@@ -3433,46 +3812,56 @@ system and gives an overview of their function and contents.
       resides in ``meta/classes/kernel-fitimage.bbclass``. You can register
       custom kernel image types with the ``kernel`` class using this
       variable.
-   
+
    KERNEL_DEVICETREE
       Specifies the name of the generated Linux kernel device tree (i.e.
       the ``.dtb``) file.
-   
+
       .. note::
-   
+
          Legacy support exists for specifying the full path to the device
-         tree. However, providing just the
-         .dtb
-         file is preferred.
-   
+         tree. However, providing just the .dtb file is preferred.
+
       In order to use this variable, the
       :ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class must
       be inherited.
-   
+
    KERNEL_DTB_LINK_NAME
       The link name of the kernel device tree binary (DTB). This variable
       is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
-      follows: KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The
+      follows:
+      ::
+
+         KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The
       value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in
-      the same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
+      the same file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
       See the :term:`MACHINE` variable for additional
       information.
-   
+
    KERNEL_DTB_NAME
       The base name of the kernel device tree binary (DTB). This variable
       is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
-      follows: KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of
-      the :term:`KERNEL_ARTIFACT_NAME`
+      follows:
+      ::
+
+         KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+
+      The value of the :term:`KERNEL_ARTIFACT_NAME`
       variable, which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    KERNEL_EXTRA_ARGS
       Specifies additional ``make`` command-line arguments the OpenEmbedded
       build system passes on when compiling the kernel.
-   
+
    KERNEL_FEATURES
       Includes additional kernel metadata. In the OpenEmbedded build
       system, the default Board Support Packages (BSPs)
@@ -3481,158 +3870,184 @@ system and gives an overview of their function and contents.
       variables. You can use the ``KERNEL_FEATURES`` variable from within
       the kernel recipe or kernel append file to further add metadata for
       all BSPs or specific BSPs.
-   
+
       The metadata you add through this variable includes config fragments
       and features descriptions, which usually includes patches as well as
       config fragments. You typically override the ``KERNEL_FEATURES``
       variable for a specific machine. In this way, you can provide
       validated, but optional, sets of kernel configurations and features.
-   
+
       For example, the following example from the ``linux-yocto-rt_4.12``
       kernel recipe adds "netfilter" and "taskstats" features to all BSPs
       as well as "virtio" configurations to all QEMU machines. The last two
       statements add specific configurations to targeted machine types:
-      KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
-      features/taskstats/taskstats.scc" KERNEL_FEATURES_append = "
-      ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemuall = "
-      cfg/virtio.scc" KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc
-      cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64 = "
-      cfg/sound.scc"
-   
+      ::
+
+         KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
+         KERNEL_FEATURES_append = "${KERNEL_EXTRA_FEATURES}"
+         KERNEL_FEATURES_append_qemuall = "cfg/virtio.scc"
+         KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
+         KERNEL_FEATURES_append_qemux86-64 = "cfg/sound.scc"
+
    KERNEL_FIT_LINK_NAME
       The link name of the kernel flattened image tree (FIT) image. This
       variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
-      file as follows: KERNEL_FIT_LINK_NAME ?=
-      "${KERNEL_ARTIFACT_LINK_NAME}" The value of the
+      file as follows:
+      ::
+
+         KERNEL_FIT_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The value of the
       ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
-      file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
+      file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
       See the :term:`MACHINE` variable for additional
       information.
-   
+
    KERNEL_FIT_NAME
       The base name of the kernel flattened image tree (FIT) image. This
       variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
-      file as follows: KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}" The
-      value of the :term:`KERNEL_ARTIFACT_NAME`
+      file as follows:
+      ::
+
+         KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+
+      The value of the :term:`KERNEL_ARTIFACT_NAME`
       variable, which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    KERNEL_IMAGE_LINK_NAME
       The link name for the kernel image. This variable is set in the
       ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
-      KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value of
+      ::
+
+         KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The value of
       the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
-      file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
+      file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
       See the :term:`MACHINE` variable for additional
       information.
-   
+
    KERNEL_IMAGE_MAXSIZE
       Specifies the maximum size of the kernel image file in kilobytes. If
       ``KERNEL_IMAGE_MAXSIZE`` is set, the size of the kernel image file is
       checked against the set value during the
       :ref:`ref-tasks-sizecheck` task. The task fails if
       the kernel image file is larger than the setting.
-   
+
       ``KERNEL_IMAGE_MAXSIZE`` is useful for target devices that have a
       limited amount of space in which the kernel image must be stored.
-   
+
       By default, this variable is not set, which means the size of the
       kernel image is not checked.
-   
+
    KERNEL_IMAGE_NAME
       The base name of the kernel image. This variable is set in the
       ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
-      KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the
+      ::
+
+         KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+
+      The value of the
       :term:`KERNEL_ARTIFACT_NAME` variable,
       which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    KERNEL_IMAGETYPE
       The type of kernel to build for a device, usually set by the machine
       configuration files and defaults to "zImage". This variable is used
       when building the kernel and is passed to ``make`` as the target to
       build.
-   
+
       If you want to build an alternate kernel image type, use the
       :term:`KERNEL_ALT_IMAGETYPE` variable.
-   
+
    KERNEL_MODULE_AUTOLOAD
       Lists kernel modules that need to be auto-loaded during boot.
-   
+
       .. note::
-   
+
          This variable replaces the deprecated
          module_autoload
          variable.
-   
+
       You can use the ``KERNEL_MODULE_AUTOLOAD`` variable anywhere that it
       can be recognized by the kernel recipe or by an out-of-tree kernel
       module recipe (e.g. a machine configuration file, a distribution
       configuration file, an append file for the recipe, or the recipe
       itself).
-   
-      Specify it as follows: KERNEL_MODULE_AUTOLOAD += "module_name1
-      module_name2 module_name3"
-   
+
+      Specify it as follows:
+      ::
+
+         KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3"
+
       Including ``KERNEL_MODULE_AUTOLOAD`` causes the OpenEmbedded build
       system to populate the ``/etc/modules-load.d/modname.conf`` file with
       the list of modules to be auto-loaded on boot. The modules appear
       one-per-line in the file. Here is an example of the most common use
-      case: KERNEL_MODULE_AUTOLOAD += "module_name"
-   
+      case:
+      ::
+
+         KERNEL_MODULE_AUTOLOAD += "module_name"
+
       For information on how to populate the ``modname.conf`` file with
-      ``modprobe.d`` syntax lines, see the
-      :term:`KERNEL_MODULE_PROBECONF`
-      variable.
-   
+      ``modprobe.d`` syntax lines, see the :term:`KERNEL_MODULE_PROBECONF` variable.
+
    KERNEL_MODULE_PROBECONF
       Provides a list of modules for which the OpenEmbedded build system
       expects to find ``module_conf_``\ modname values that specify
       configuration for each of the modules. For information on how to
       provide those module configurations, see the
       :term:`module_conf_* <module_conf>` variable.
-   
+
    KERNEL_PATH
       The location of the kernel sources. This variable is set to the value
       of the :term:`STAGING_KERNEL_DIR` within
       the :ref:`module <ref-classes-module>` class. For information on
-      how this variable is used, see the "`Incorporating Out-of-Tree
-      Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__"
+      how this variable is used, see the
+      ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
       section in the Yocto Project Linux Kernel Development Manual.
-   
+
       To help maximize compatibility with out-of-tree drivers used to build
       modules, the OpenEmbedded build system also recognizes and uses the
       :term:`KERNEL_SRC` variable, which is identical to
       the ``KERNEL_PATH`` variable. Both variables are common variables
       used by external Makefiles to point to the kernel source directory.
-   
+
    KERNEL_SRC
       The location of the kernel sources. This variable is set to the value
       of the :term:`STAGING_KERNEL_DIR` within
       the :ref:`module <ref-classes-module>` class. For information on
-      how this variable is used, see the "`Incorporating Out-of-Tree
-      Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__"
+      how this variable is used, see the
+      ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
       section in the Yocto Project Linux Kernel Development Manual.
-   
+
       To help maximize compatibility with out-of-tree drivers used to build
       modules, the OpenEmbedded build system also recognizes and uses the
       :term:`KERNEL_PATH` variable, which is identical
       to the ``KERNEL_SRC`` variable. Both variables are common variables
       used by external Makefiles to point to the kernel source directory.
-   
+
    KERNEL_VERSION
       Specifies the version of the kernel as extracted from ``version.h``
       or ``utsrelease.h`` within the kernel sources. Effects of setting
       this variable do not take affect until the kernel has been
       configured. Consequently, attempting to refer to this variable in
       contexts prior to configuration will not work.
-   
+
    KERNELDEPMODDEPEND
       Specifies whether the data referenced through
       :term:`PKGDATA_DIR` is needed or not. The
@@ -3641,14 +4056,16 @@ system and gives an overview of their function and contents.
       use the data, set the ``KERNELDEPMODDEPEND`` variable in your
       ``initramfs`` recipe. Setting the variable there when the data is not
       needed avoids a potential dependency loop.
-   
+
    KFEATURE_DESCRIPTION
       Provides a short description of a configuration fragment. You use
       this variable in the ``.scc`` file that describes a configuration
       fragment file. Here is the variable used in a file named ``smp.scc``
-      to describe SMP being enabled: define KFEATURE_DESCRIPTION "Enable
-      SMP"
-   
+      to describe SMP being enabled:
+      ::
+
+          define KFEATURE_DESCRIPTION "Enable SMP"
+
    KMACHINE
       The machine as known by the kernel. Sometimes the machine name used
       by the kernel does not match the machine name used by the
@@ -3658,77 +4075,86 @@ system and gives an overview of their function and contents.
       understands that machine as ``intel-core2-32``. For cases like these,
       the ``KMACHINE`` variable maps the kernel machine name to the
       OpenEmbedded build system machine name.
-   
+
       These mappings between different names occur in the Yocto Linux
       Kernel's ``meta`` branch. As an example take a look in the
       ``common/recipes-kernel/linux/linux-yocto_3.19.bbappend`` file:
-      LINUX_VERSION_core2-32-intel-common = "3.19.0"
-      COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
-      SRCREV_meta_core2-32-intel-common =
-      "8897ef68b30e7426bc1d39895e71fb155d694974"
-      SRCREV_machine_core2-32-intel-common =
-      "43b9eced9ba8a57add36af07736344dcc383f711"
-      KMACHINE_core2-32-intel-common = "intel-core2-32"
-      KBRANCH_core2-32-intel-common = "standard/base"
-      KERNEL_FEATURES_append_core2-32-intel-common =
-      "${KERNEL_FEATURES_INTEL_COMMON}" The ``KMACHINE`` statement says
+      ::
+
+         LINUX_VERSION_core2-32-intel-common = "3.19.0"
+         COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+         SRCREV_meta_core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974"
+         SRCREV_machine_core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
+         KMACHINE_core2-32-intel-common = "intel-core2-32"
+         KBRANCH_core2-32-intel-common = "standard/base"
+         KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
+
+      The ``KMACHINE`` statement says
       that the kernel understands the machine name as "intel-core2-32".
       However, the OpenEmbedded build system understands the machine as
       "core2-32-intel-common".
-   
+
    KTYPE
       Defines the kernel type to be used in assembling the configuration.
       The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
-      kernel types. See the "`Kernel
-      Types <&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types>`__" section in the
+      kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+      section in the
       Yocto Project Linux Kernel Development Manual for more information on
       kernel types.
-   
-      You define the ``KTYPE`` variable in the `BSP
-      Descriptions <&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions>`__. The
+
+      You define the ``KTYPE`` variable in the
+      :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`. The
       value you use must match the value used for the
       :term:`LINUX_KERNEL_TYPE` value used by the
       kernel recipe.
-   
+
    LABELS
       Provides a list of targets for automatic configuration.
-   
+
       See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
       information on how this variable is used.
-   
+
    LAYERDEPENDS
       Lists the layers, separated by spaces, on which this recipe depends.
       Optionally, you can specify a specific layer version for a dependency
       by adding it to the end of the layer name. Here is an example:
-      LAYERDEPENDS_mylayer = "anotherlayer (=3)" In this previous example,
+      ::
+
+         LAYERDEPENDS_mylayer = "anotherlayer (=3)"
+
+      In this previous example,
       version 3 of "anotherlayer" is compared against
       :term:`LAYERVERSION`\ ``_anotherlayer``.
-   
+
       An error is produced if any dependency is missing or the version
       numbers (if specified) do not match exactly. This variable is used in
       the ``conf/layer.conf`` file and must be suffixed with the name of
       the specific layer (e.g. ``LAYERDEPENDS_mylayer``).
-   
+
    LAYERDIR
       When used inside the ``layer.conf`` configuration file, this variable
       provides the path of the current layer. This variable is not
       available outside of ``layer.conf`` and references are expanded
       immediately when parsing of the file completes.
-   
+
    LAYERRECOMMENDS
       Lists the layers, separated by spaces, recommended for use with this
       layer.
-   
+
       Optionally, you can specify a specific layer version for a
       recommendation by adding the version to the end of the layer name.
-      Here is an example: LAYERRECOMMENDS_mylayer = "anotherlayer (=3)" In
-      this previous example, version 3 of "anotherlayer" is compared
+      Here is an example:
+      ::
+
+         LAYERRECOMMENDS_mylayer = "anotherlayer (=3)"
+
+      In this previous example, version 3 of "anotherlayer" is compared
       against ``LAYERVERSION_anotherlayer``.
-   
+
       This variable is used in the ``conf/layer.conf`` file and must be
       suffixed with the name of the specific layer (e.g.
       ``LAYERRECOMMENDS_mylayer``).
-   
+
    LAYERSERIES_COMPAT
       Lists the versions of the :term:`OpenEmbedded-Core (OE-Core)` for which
       a layer is compatible. Using the ``LAYERSERIES_COMPAT`` variable
@@ -3736,27 +4162,28 @@ system and gives an overview of their function and contents.
       layer and OE-Core can be expected to work. The variable gives the
       system a way to detect when a layer has not been tested with new
       releases of OE-Core (e.g. the layer is not maintained).
-   
+
       To specify the OE-Core versions for which a layer is compatible, use
       this variable in your layer's ``conf/layer.conf`` configuration file.
       For the list, use the Yocto Project
       :yocto_wiki:`Release Name </wiki/Releases>` (e.g.
       DISTRO_NAME_NO_CAP). To specify multiple OE-Core versions for the
-      layer, use a space-separated list: LAYERSERIES_COMPAT_layer_root_name
-      = "DISTRO_NAME_NO_CAP DISTRO_NAME_NO_CAP_MINUS_ONE"
-   
+      layer, use a space-separated list:
+      ::
+
+         LAYERSERIES_COMPAT_layer_root_name = "DISTRO_NAME_NO_CAP DISTRO_NAME_NO_CAP_MINUS_ONE"
+
       .. note::
-   
+
          Setting
          LAYERSERIES_COMPAT
          is required by the Yocto Project Compatible version 2 standard.
          The OpenEmbedded build system produces a warning if the variable
          is not set for any given layer.
-   
-      See the "`Creating Your Own
-      Layer <&YOCTO_DOCS_DEV_URL;#creating-your-own-layer>`__" section in
-      the Yocto Project Development Tasks Manual.
-   
+
+      See the ":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+      section in the Yocto Project Development Tasks Manual.
+
    LAYERVERSION
       Optionally specifies the version of a layer as a single number. You
       can use this within :term:`LAYERDEPENDS` for
@@ -3764,90 +4191,98 @@ system and gives an overview of their function and contents.
       This variable is used in the ``conf/layer.conf`` file and must be
       suffixed with the name of the specific layer (e.g.
       ``LAYERVERSION_mylayer``).
-   
+
    LD
       The minimal command and arguments used to run the linker.
-   
+
    LDFLAGS
       Specifies the flags to pass to the linker. This variable is exported
       to an environment variable and thus made visible to the software
       being built during the compilation step.
-   
+
       Default initialization for ``LDFLAGS`` varies depending on what is
       being built:
-   
+
       -  :term:`TARGET_LDFLAGS` when building for the
          target
-   
+
       -  :term:`BUILD_LDFLAGS` when building for the
          build host (i.e. ``-native``)
-   
+
       -  :term:`BUILDSDK_LDFLAGS` when building for
          an SDK (i.e. ``nativesdk-``)
-   
+
    LEAD_SONAME
       Specifies the lead (or primary) compiled library file (i.e. ``.so``)
       that the :ref:`debian <ref-classes-debian>` class applies its
       naming policy to given a recipe that packages multiple libraries.
-   
+
       This variable works in conjunction with the ``debian`` class.
-   
+
    LIC_FILES_CHKSUM
       Checksums of the license text in the recipe source code.
-   
+
       This variable tracks changes in license text of the source code
       files. If the license text is changed, it will trigger a build
       failure, which gives the developer an opportunity to review any
       license change.
-   
+
       This variable must be defined for all recipes (unless
       :term:`LICENSE` is set to "CLOSED").
-   
-      For more information, see the "`Tracking License
-      Changes <&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-LIC_FILES_CHKSUM>`__"
+
+      For more information, see the ":ref:`usingpoky-configuring-lic_files_chksum`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    LICENSE
       The list of source licenses for the recipe. Follow these rules:
-   
+
       -  Do not use spaces within individual license names.
-   
+
       -  Separate license names using \| (pipe) when there is a choice
          between licenses.
-   
+
       -  Separate license names using & (ampersand) when multiple licenses
          exist that cover different parts of the source.
-   
+
       -  You can use spaces between license names.
-   
+
       -  For standard licenses, use the names of the files in
          ``meta/files/common-licenses/`` or the
          :term:`SPDXLICENSEMAP` flag names defined in
          ``meta/conf/licenses.conf``.
-   
-      Here are some examples: LICENSE = "LGPLv2.1 \| GPLv3" LICENSE =
-      "MPL-1 & LGPLv2.1" LICENSE = "GPLv2+" The first example is from the
+
+      Here are some examples:
+      ::
+
+         LICENSE = "LGPLv2.1 | GPLv3"
+         LICENSE = "MPL-1 & LGPLv2.1"
+         LICENSE = "GPLv2+"
+
+      The first example is from the
       recipes for Qt, which the user may choose to distribute under either
       the LGPL version 2.1 or GPL version 3. The second example is from
       Cairo where two licenses cover different parts of the source code.
       The final example is from ``sysstat``, which presents a single
       license.
-   
+
       You can also specify licenses on a per-package basis to handle
       situations where components of the output have different licenses.
       For example, a piece of software whose code is licensed under GPLv2
       but has accompanying documentation licensed under the GNU Free
-      Documentation License 1.2 could be specified as follows: LICENSE =
-      "GFDL-1.2 & GPLv2" LICENSE_${PN} = "GPLv2" LICENSE_${PN}-doc =
-      "GFDL-1.2"
-   
+      Documentation License 1.2 could be specified as follows:
+      ::
+
+         LICENSE = "GFDL-1.2 & GPLv2"
+         LICENSE_${PN} = "GPLv2"
+         LICENSE_${PN}-doc = "GFDL-1.2"
+
    LICENSE_CREATE_PACKAGE
       Setting ``LICENSE_CREATE_PACKAGE`` to "1" causes the OpenEmbedded
       build system to create an extra package (i.e.
       ``${``\ :term:`PN`\ ``}-lic``) for each recipe and to add
       those packages to the
       :term:`RRECOMMENDS`\ ``_${PN}``.
-   
+
       The ``${PN}-lic`` package installs a directory in
       ``/usr/share/licenses`` named ``${PN}``, which is the recipe's base
       name, and installs files in that directory that contain license and
@@ -3857,124 +4292,149 @@ system and gives an overview of their function and contents.
       and copies of files marked in
       :term:`LIC_FILES_CHKSUM` as containing
       license text).
-   
+
       For related information on providing license text, see the
       :term:`COPY_LIC_DIRS` variable, the
       :term:`COPY_LIC_MANIFEST` variable, and the
-      "`Providing License
-      Text <&YOCTO_DOCS_DEV_URL;#providing-license-text>`__" section in the
-      Yocto Project Development Tasks Manual.
-   
+      ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+      section in the Yocto Project Development Tasks Manual.
+
    LICENSE_FLAGS
       Specifies additional flags for a recipe you must whitelist through
       :term:`LICENSE_FLAGS_WHITELIST` in
       order to allow the recipe to be built. When providing multiple flags,
       separate them with spaces.
-   
+
       This value is independent of :term:`LICENSE` and is
       typically used to mark recipes that might require additional licenses
       in order to be used in a commercial product. For more information,
-      see the "`Enabling Commercially Licensed
-      Recipes <&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes>`__"
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    LICENSE_FLAGS_WHITELIST
       Lists license flags that when specified in
       :term:`LICENSE_FLAGS` within a recipe should not
       prevent that recipe from being built. This practice is otherwise
       known as "whitelisting" license flags. For more information, see the
-      "`Enabling Commercially Licensed
-      Recipes <&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    LICENSE_PATH
       Path to additional licenses used during the build. By default, the
       OpenEmbedded build system uses ``COMMON_LICENSE_DIR`` to define the
       directory that holds common license text used during the build. The
       ``LICENSE_PATH`` variable allows you to extend that location to other
-      areas that have additional licenses: LICENSE_PATH +=
-      "path-to-additional-common-licenses"
-   
+      areas that have additional licenses:
+      ::
+
+         LICENSE_PATH += "path-to-additional-common-licenses"
+
    LINUX_KERNEL_TYPE
       Defines the kernel type to be used in assembling the configuration.
       The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
-      kernel types. See the "`Kernel
-      Types <&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types>`__" section in the
+      kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+      section in the
       Yocto Project Linux Kernel Development Manual for more information on
       kernel types.
-   
+
       If you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to
       "standard". Together with :term:`KMACHINE`, the
       ``LINUX_KERNEL_TYPE`` variable defines the search arguments used by
       the kernel tools to find the appropriate description within the
       kernel :term:`Metadata` with which to build out the sources
       and configuration.
-   
+
    LINUX_VERSION
       The Linux version from ``kernel.org`` on which the Linux kernel image
       being built using the OpenEmbedded build system is based. You define
       this variable in the kernel recipe. For example, the
       ``linux-yocto-3.4.bb`` kernel recipe found in
       ``meta/recipes-kernel/linux`` defines the variables as follows:
-      LINUX_VERSION ?= "3.4.24"
-   
+      ::
+
+         LINUX_VERSION ?= "3.4.24"
+
       The ``LINUX_VERSION`` variable is used to define :term:`PV`
-      for the recipe: PV = "${LINUX_VERSION}+git${SRCPV}"
-   
+      for the recipe:
+      ::
+
+         PV = "${LINUX_VERSION}+git${SRCPV}"
+
    LINUX_VERSION_EXTENSION
       A string extension compiled into the version string of the Linux
       kernel built with the OpenEmbedded build system. You define this
       variable in the kernel recipe. For example, the linux-yocto kernel
-      recipes all define the variable as follows: LINUX_VERSION_EXTENSION
-      ?= "-yocto-${:term:`LINUX_KERNEL_TYPE`}"
-   
+      recipes all define the variable as follows:
+      ::
+
+         LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+
       Defining this variable essentially sets the Linux kernel
       configuration item ``CONFIG_LOCALVERSION``, which is visible through
       the ``uname`` command. Here is an example that shows the extension
-      assuming it was set as previously shown: $ uname -r 3.7.0-rc8-custom
-   
+      assuming it was set as previously shown:
+      ::
+
+         $ uname -r
+         3.7.0-rc8-custom
+
    LOG_DIR
       Specifies the directory to which the OpenEmbedded build system writes
       overall log files. The default directory is ``${TMPDIR}/log``.
-   
+
       For the directory containing logs specific to each task, see the
       :term:`T` variable.
-   
+
    MACHINE
       Specifies the target device for which the image is built. You define
       ``MACHINE`` in the ``local.conf`` file found in the
       :term:`Build Directory`. By default, ``MACHINE`` is set to
       "qemux86", which is an x86-based architecture machine to be emulated
-      using QEMU: MACHINE ?= "qemux86"
-   
+      using QEMU:
+      ::
+
+         MACHINE ?= "qemux86"
+
       The variable corresponds to a machine configuration file of the same
       name, through which machine-specific configurations are set. Thus,
       when ``MACHINE`` is set to "qemux86" there exists the corresponding
       ``qemux86.conf`` machine configuration file, which can be found in
       the :term:`Source Directory` in
       ``meta/conf/machine``.
-   
+
       The list of machines supported by the Yocto Project as shipped
-      include the following: MACHINE ?= "qemuarm" MACHINE ?= "qemuarm64"
-      MACHINE ?= "qemumips" MACHINE ?= "qemumips64" MACHINE ?= "qemuppc"
-      MACHINE ?= "qemux86" MACHINE ?= "qemux86-64" MACHINE ?= "genericx86"
-      MACHINE ?= "genericx86-64" MACHINE ?= "beaglebone" MACHINE ?=
-      "edgerouter" The last five are Yocto Project reference hardware
+      include the following:
+      ::
+
+         MACHINE ?= "qemuarm"
+         MACHINE ?= "qemuarm64"
+         MACHINE ?= "qemumips"
+         MACHINE ?= "qemumips64"
+         MACHINE ?= "qemuppc"
+         MACHINE ?= "qemux86"
+         MACHINE ?= "qemux86-64"
+         MACHINE ?= "genericx86"
+         MACHINE ?= "genericx86-64"
+         MACHINE ?= "beaglebone"
+         MACHINE ?= "edgerouter"
+
+      The last five are Yocto Project reference hardware
       boards, which are provided in the ``meta-yocto-bsp`` layer.
-   
+
       .. note::
-   
+
          Adding additional Board Support Package (BSP) layers to your
          configuration adds new possible settings for
          MACHINE
          .
-   
+
    MACHINE_ARCH
       Specifies the name of the machine-specific architecture. This
       variable is set automatically from :term:`MACHINE` or
       :term:`TUNE_PKGARCH`. You should not hand-edit
       the ``MACHINE_ARCH`` variable.
-   
+
    MACHINE_ESSENTIAL_EXTRA_RDEPENDS
       A list of required machine-specific packages to install as part of
       the image being built. The build process depends on these packages
@@ -3983,19 +4443,21 @@ system and gives an overview of their function and contents.
       The impact of this variable affects images based on
       ``packagegroup-core-boot``, including the ``core-image-minimal``
       image.
-   
+
       This variable is similar to the
       ``MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` variable with the exception
       that the image being built has a build dependency on the variable's
       list of packages. In other words, the image will not build if a file
       in this list is not found.
-   
+
       As an example, suppose the machine for which you are building
       requires ``example-init`` to be run during boot to initialize the
       hardware. In this case, you would use the following in the machine's
-      ``.conf`` configuration file: MACHINE_ESSENTIAL_EXTRA_RDEPENDS +=
-      "example-init"
-   
+      ``.conf`` configuration file:
+      ::
+
+         MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
+
    MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS
       A list of recommended machine-specific packages to install as part of
       the image being built. The build process does not depend on these
@@ -4004,7 +4466,7 @@ system and gives an overview of their function and contents.
       the machine to boot. The impact of this variable affects images based
       on ``packagegroup-core-boot``, including the ``core-image-minimal``
       image.
-   
+
       This variable is similar to the ``MACHINE_ESSENTIAL_EXTRA_RDEPENDS``
       variable with the exception that the image being built does not have
       a build dependency on the variable's list of packages. In other
@@ -4013,7 +4475,7 @@ system and gives an overview of their function and contents.
       modules, whose functionality may be selected to be built into the
       kernel rather than as a module, in which case a package will not be
       produced.
-   
+
       Consider an example where you have a custom kernel where a specific
       touchscreen driver is required for the machine to be usable. However,
       the driver can be built as a module or into the kernel depending on
@@ -4024,10 +4486,12 @@ system and gives an overview of their function and contents.
       not fail due to the missing package. To accomplish this, assuming the
       package for the module was called ``kernel-module-ab123``, you would
       use the following in the machine's ``.conf`` configuration file:
-      MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
-   
+      ::
+
+         MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
+
       .. note::
-   
+
          In this example, the
          kernel-module-ab123
          recipe needs to explicitly set its
@@ -4035,25 +4499,25 @@ system and gives an overview of their function and contents.
          variable to ensure that BitBake does not use the kernel recipe's
          PACKAGES_DYNAMIC
          variable to satisfy the dependency.
-   
+
       Some examples of these machine essentials are flash, screen,
       keyboard, mouse, or touchscreen drivers (depending on the machine).
-   
+
    MACHINE_EXTRA_RDEPENDS
       A list of machine-specific packages to install as part of the image
       being built that are not essential for the machine to boot. However,
       the build process for more fully-featured images depends on the
       packages being present.
-   
+
       This variable affects all images based on ``packagegroup-base``,
       which does not include the ``core-image-minimal`` or
       ``core-image-full-cmdline`` images.
-   
+
       The variable is similar to the ``MACHINE_EXTRA_RRECOMMENDS`` variable
       with the exception that the image being built has a build dependency
       on the variable's list of packages. In other words, the image will
       not build if a file in this list is not found.
-   
+
       An example is a machine that has WiFi capability but is not essential
       for the machine to boot the image. However, if you are building a
       more fully-featured image, you want to enable the WiFi. The package
@@ -4062,22 +4526,24 @@ system and gives an overview of their function and contents.
       finding the package. In this case, assuming the package for the
       firmware was called ``wifidriver-firmware``, you would use the
       following in the ``.conf`` file for the machine:
-      MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
-   
+      ::
+
+         MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
+
    MACHINE_EXTRA_RRECOMMENDS
       A list of machine-specific packages to install as part of the image
       being built that are not essential for booting the machine. The image
       being built has no build dependency on this list of packages.
-   
+
       This variable affects only images based on ``packagegroup-base``,
       which does not include the ``core-image-minimal`` or
       ``core-image-full-cmdline`` images.
-   
+
       This variable is similar to the ``MACHINE_EXTRA_RDEPENDS`` variable
       with the exception that the image being built does not have a build
       dependency on the variable's list of packages. In other words, the
       image will build if a file in this list is not found.
-   
+
       An example is a machine that has WiFi capability but is not essential
       For the machine to boot the image. However, if you are building a
       more fully-featured image, you want to enable WiFi. In this case, the
@@ -4087,8 +4553,10 @@ system and gives an overview of their function and contents.
       not being found. To accomplish this, assuming the package for the
       module was called ``kernel-module-examplewifi``, you would use the
       following in the ``.conf`` file for the machine:
-      MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
-   
+      ::
+
+         MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
+
    MACHINE_FEATURES
       Specifies the list of hardware features the
       :term:`MACHINE` is capable of supporting. For related
@@ -4096,48 +4564,59 @@ system and gives an overview of their function and contents.
       :term:`DISTRO_FEATURES`,
       :term:`COMBINED_FEATURES`, and
       :term:`IMAGE_FEATURES` variables.
-   
+
       For a list of hardware features supported by the Yocto Project as
       shipped, see the "`Machine Features <#ref-features-machine>`__"
       section.
-   
+
    MACHINE_FEATURES_BACKFILL
       Features to be added to ``MACHINE_FEATURES`` if not also present in
       ``MACHINE_FEATURES_BACKFILL_CONSIDERED``.
-   
+
       This variable is set in the ``meta/conf/bitbake.conf`` file. It is
       not intended to be user-configurable. It is best to just reference
       the variable to see which machine features are being backfilled for
       all machine configurations. See the "`Feature
       Backfilling <#ref-features-backfill>`__" section for more
       information.
-   
+
    MACHINE_FEATURES_BACKFILL_CONSIDERED
       Features from ``MACHINE_FEATURES_BACKFILL`` that should not be
       backfilled (i.e. added to ``MACHINE_FEATURES``) during the build. See
       the "`Feature Backfilling <#ref-features-backfill>`__" section for
       more information.
-   
+
    MACHINEOVERRIDES
       A colon-separated list of overrides that apply to the current
       machine. By default, this list includes the value of
       :term:`MACHINE`.
-   
+
       You can extend ``MACHINEOVERRIDES`` to add extra overrides that
       should apply to a machine. For example, all machines emulated in QEMU
       (e.g. ``qemuarm``, ``qemux86``, and so forth) include a file named
       ``meta/conf/machine/include/qemu.inc`` that prepends the following
-      override to ``MACHINEOVERRIDES``: MACHINEOVERRIDES =. "qemuall:" This
+      override to ``MACHINEOVERRIDES``:
+      ::
+
+         MACHINEOVERRIDES =. "qemuall:"
+
+      This
       override allows variables to be overriden for all machines emulated
       in QEMU, like in the following example from the ``connman-conf``
-      recipe: SRC_URI_append_qemuall = "file://wired.config \\
-      file://wired-setup \\ " The underlying mechanism behind
+      recipe:
+      ::
+
+         SRC_URI_append_qemuall = "file://wired.config \
+             file://wired-setup \
+             "
+
+      The underlying mechanism behind
       ``MACHINEOVERRIDES`` is simply that it is included in the default
       value of :term:`OVERRIDES`.
-   
+
    MAINTAINER
       The email address of the distribution maintainer.
-   
+
    MIRRORS
       Specifies additional paths from which the OpenEmbedded build system
       gets source code. When the build system searches for source code, it
@@ -4145,20 +4624,20 @@ system and gives an overview of their function and contents.
       build system tries locations defined by
       :term:`PREMIRRORS`, the upstream source, and then
       locations specified by ``MIRRORS`` in that order.
-   
+
       Assuming your distribution (:term:`DISTRO`) is "poky",
       the default value for ``MIRRORS`` is defined in the
       ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
-   
+
    MLPREFIX
       Specifies a prefix has been added to :term:`PN` to create a
       special version of a recipe or package (i.e. a Multilib version). The
       variable is used in places where the prefix needs to be added to or
       removed from a the name (e.g. the :term:`BPN` variable).
       ``MLPREFIX`` gets set when a prefix has been added to ``PN``.
-   
+
       .. note::
-   
+
          The "ML" in
          MLPREFIX
          stands for "MultiLib". This representation is historical and comes
@@ -4169,7 +4648,7 @@ system and gives an overview of their function and contents.
          was turned into a prefix, it made sense to set
          MLPREFIX
          for it as well.
-   
+
       To help understand when ``MLPREFIX`` might be needed, consider when
       :term:`BBCLASSEXTEND` is used to provide a
       ``nativesdk`` version of a recipe in addition to the target version.
@@ -4177,25 +4656,37 @@ system and gives an overview of their function and contents.
       recipes by using :term:`DEPENDS`, then a dependency on
       "foo" will automatically get rewritten to a dependency on
       "nativesdk-foo". However, dependencies like the following will not
-      get rewritten automatically: do_foo[depends] += "recipe:do_foo" If
-      you want such a dependency to also get transformed, you can do the
-      following: do_foo[depends] += "${MLPREFIX}recipe:do_foo"
-   
+      get rewritten automatically:
+      ::
+
+         do_foo[depends] += "recipe:do_foo"
+
+      If you want such a dependency to also get transformed, you can do the
+      following:
+      ::
+
+         do_foo[depends] += "${MLPREFIX}recipe:do_foo"
+
    module_autoload
       This variable has been replaced by the ``KERNEL_MODULE_AUTOLOAD``
       variable. You should replace all occurrences of ``module_autoload``
       with additions to ``KERNEL_MODULE_AUTOLOAD``, for example:
-      module_autoload_rfcomm = "rfcomm"
-   
-      should now be replaced with: KERNEL_MODULE_AUTOLOAD += "rfcomm" See
-      the :term:`KERNEL_MODULE_AUTOLOAD`
-      variable for more information.
-   
+      ::
+
+         module_autoload_rfcomm = "rfcomm"
+
+      should now be replaced with:
+      ::
+
+         KERNEL_MODULE_AUTOLOAD += "rfcomm"
+
+      See the :term:`KERNEL_MODULE_AUTOLOAD` variable for more information.
+
    module_conf
-      Specifies ```modprobe.d`http://linux.die.net/man/5/modprobe.d
+      Specifies `modprobe.d <http://linux.die.net/man/5/modprobe.d>`_
       syntax lines for inclusion in the ``/etc/modprobe.d/modname.conf``
       file.
-   
+
       You can use this variable anywhere that it can be recognized by the
       kernel recipe or out-of-tree kernel module recipe (e.g. a machine
       configuration file, a distribution configuration file, an append file
@@ -4203,64 +4694,80 @@ system and gives an overview of their function and contents.
       must also be sure to list the module name in the
       :term:`KERNEL_MODULE_AUTOLOAD`
       variable.
-   
-      Here is the general syntax: module_conf_module_name =
-      "modprobe.d-syntax" You must use the kernel module name override.
-   
+
+      Here is the general syntax:
+      ::
+
+         module_conf_module_name = "modprobe.d-syntax"
+
+      You must use the kernel module name override.
+
       Run ``man modprobe.d`` in the shell to find out more information on
       the exact syntax you want to provide with ``module_conf``.
-   
+
       Including ``module_conf`` causes the OpenEmbedded build system to
       populate the ``/etc/modprobe.d/modname.conf`` file with
       ``modprobe.d`` syntax lines. Here is an example that adds the options
       ``arg1`` and ``arg2`` to a module named ``mymodule``:
-      module_conf_mymodule = "options mymodule arg1=val1 arg2=val2"
-   
+      ::
+
+         module_conf_mymodule = "options mymodule arg1=val1 arg2=val2"
+
       For information on how to specify kernel modules to auto-load on
-      boot, see the
-      :term:`KERNEL_MODULE_AUTOLOAD`
-      variable.
-   
+      boot, see the :term:`KERNEL_MODULE_AUTOLOAD` variable.
+
    MODULE_TARBALL_DEPLOY
       Controls creation of the ``modules-*.tgz`` file. Set this variable to
       "0" to disable creation of this file, which contains all of the
       kernel modules resulting from a kernel build.
-   
+
    MODULE_TARBALL_LINK_NAME
       The link name of the kernel module tarball. This variable is set in
       the ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
-      MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value
+      ::
+
+         MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The value
       of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the
-      same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
-      See the :term:`MACHINE` variable for additional
-      information.
-   
+      same file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
+      See the :term:`MACHINE` variable for additional information.
+
    MODULE_TARBALL_NAME
       The base name of the kernel module tarball. This variable is set in
       the ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
-      MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the
-      :term:`KERNEL_ARTIFACT_NAME` variable,
+      ::
+
+         MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+
+      The value of the :term:`KERNEL_ARTIFACT_NAME` variable,
       which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    MULTIMACH_TARGET_SYS
       Uniquely identifies the type of the target system for which packages
       are being built. This variable allows output for different types of
       target systems to be put into different subdirectories of the same
       output directory.
-   
+
       The default value of this variable is:
-      ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS} Some classes (e.g.
+      ::
+
+         ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}
+
+      Some classes (e.g.
       :ref:`cross-canadian <ref-classes-cross-canadian>`) modify the
       ``MULTIMACH_TARGET_SYS`` value.
-   
+
       See the :term:`STAMP` variable for an example. See the
-      :term:`STAGING_DIR_TARGET` variable for
-      more information.
-   
+      :term:`STAGING_DIR_TARGET` variable for more information.
+
    NATIVELSBSTRING
       A string identifying the host distribution. Strings consist of the
       host distributor ID followed by the release, as reported by the
@@ -4268,17 +4775,17 @@ system and gives an overview of their function and contents.
       example, when running a build on Ubuntu 12.10, the value is
       "Ubuntu-12.10". If this information is unable to be determined, the
       value resolves to "Unknown".
-   
+
       This variable is used by default to isolate native shared state
       packages for different distributions (e.g. to avoid problems with
       ``glibc`` version incompatibilities). Additionally, the variable is
       checked against
       :term:`SANITY_TESTED_DISTROS` if that
       variable is set.
-   
+
    NM
       The minimal command and arguments to run ``nm``.
-   
+
    NO_GENERIC_LICENSE
       Avoids QA errors when you use a non-common, non-CLOSED license in a
       recipe. Packages exist, such as the linux-firmware package, with many
@@ -4287,60 +4794,71 @@ system and gives an overview of their function and contents.
       which are only applicable to a specific package.
       ``NO_GENERIC_LICENSE`` is used to allow copying a license that does
       not exist in common licenses.
-   
+
       The following example shows how to add ``NO_GENERIC_LICENSE`` to a
-      recipe: NO_GENERIC_LICENSE[license_name] =
-      "license_file_in_fetched_source" The following is an example that
+      recipe:
+      ::
+
+         NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source"
+
+      The following is an example that
       uses the ``LICENSE.Abilis.txt`` file as the license from the fetched
-      source: NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
-   
+      source:
+      ::
+
+         NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
+
    NO_RECOMMENDATIONS
       Prevents installation of all "recommended-only" packages.
       Recommended-only packages are packages installed only through the
       :term:`RRECOMMENDS` variable). Setting the
-      ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on:
-      NO_RECOMMENDATIONS = "1"
-   
+      ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on: ::
+
+         NO_RECOMMENDATIONS = "1"
+
       You can set this variable globally in your ``local.conf`` file or you
       can attach it to a specific image recipe by using the recipe name
-      override: NO_RECOMMENDATIONS_pn-target_image = "1"
-   
+      override: ::
+
+         NO_RECOMMENDATIONS_pn-target_image = "1"
+
       It is important to realize that if you choose to not install packages
       using this variable and some other packages are dependent on them
       (i.e. listed in a recipe's :term:`RDEPENDS`
       variable), the OpenEmbedded build system ignores your request and
       will install the packages to avoid dependency errors.
-   
+
       .. note::
-   
+
          Some recommended packages might be required for certain system
          functionality, such as kernel modules. It is up to you to add
-         packages with the
-         IMAGE_INSTALL
-         variable.
-   
+         packages with the IMAGE_INSTALL variable.
+
       Support for this variable exists only when using the IPK and RPM
       packaging backend. Support does not exist for DEB.
-   
+
       See the :term:`BAD_RECOMMENDATIONS` and
       the :term:`PACKAGE_EXCLUDE` variables for
       related information.
-   
+
    NOAUTOPACKAGEDEBUG
       Disables auto package from splitting ``.debug`` files. If a recipe
       requires ``FILES_${PN}-dbg`` to be set manually, the
       ``NOAUTOPACKAGEDEBUG`` can be defined allowing you to define the
-      content of the debug package. For example: NOAUTOPACKAGEDEBUG = "1"
-      FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*" FILES_${PN}-dbg
-      = "/usr/src/debug/" FILES_${QT_BASE_NAME}-demos-doc =
-      "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
-   
+      content of the debug package. For example:
+      ::
+
+         NOAUTOPACKAGEDEBUG = "1"
+         FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
+         FILES_${PN}-dbg = "/usr/src/debug/"
+         FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
+
    OBJCOPY
       The minimal command and arguments to run ``objcopy``.
-   
+
    OBJDUMP
       The minimal command and arguments to run ``objdump``.
-   
+
    OE_BINCONFIG_EXTRA_MANGLE
       When inheriting the :ref:`binconfig <ref-classes-binconfig>` class,
       this variable specifies additional arguments passed to the "sed"
@@ -4349,60 +4867,66 @@ system and gives an overview of their function and contents.
       results in all paths in these scripts being changed to point into the
       ``sysroots/`` directory so that all builds that use the script will
       use the correct directories for the cross compiling layout.
-   
-      See the ``meta/classes/binconfig.bbclass`` in the 
+
+      See the ``meta/classes/binconfig.bbclass`` in the
       :term:`Source Directory` for details on how this class
       applies these additional sed command arguments. For general
       information on the ``binconfig`` class, see the
       ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
-   
+
    OE_IMPORTS
       An internal variable used to tell the OpenEmbedded build system what
       Python modules to import for every Python function run by the system.
-   
+
       .. note::
-   
+
          Do not set this variable. It is for internal use only.
-   
+
    OE_INIT_ENV_SCRIPT
       The name of the build environment setup script for the purposes of
       setting up the environment within the extensible SDK. The default
       value is "oe-init-build-env".
-   
+
       If you use a custom script to set up your build environment, set the
       ``OE_INIT_ENV_SCRIPT`` variable to its name.
-   
+
    OE_TERMINAL
       Controls how the OpenEmbedded build system spawns interactive
       terminals on the host development system (e.g. using the BitBake
       command with the ``-c devshell`` command-line option). For more
-      information, see the "`Using a Development
-      Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell>`__" section in
+      information, see the ":ref:`platdev-appdev-devshell`" section in
       the Yocto Project Development Tasks Manual.
-   
+
       You can use the following values for the ``OE_TERMINAL`` variable:
-      auto gnome xfce rxvt screen konsole none
-   
+
+      - auto
+      - gnome
+      - xfce
+      - rxvt
+      - screen
+      - konsole
+      - none
+
    OEROOT
       The directory from which the top-level build environment setup script
       is sourced. The Yocto Project provides a top-level build environment
       setup script: ````` <#structure-core-script>`__. When you run this
       script, the ``OEROOT`` variable resolves to the directory that
       contains the script.
-   
+
       For additional information on how this variable is used, see the
       initialization script.
-   
+
    OLDEST_KERNEL
       Declares the oldest version of the Linux kernel that the produced
       binaries must support. This variable is passed into the build of the
       Embedded GNU C Library (``glibc``).
-   
+
       The default for this variable comes from the
       ``meta/conf/bitbake.conf`` configuration file. You can override this
       default by setting the variable in a custom distribution
       configuration file.
-   
+
    OVERRIDES
       A colon-separated list of overrides that currently apply. Overrides
       are a BitBake mechanism that allows variables to be selectively
@@ -4410,26 +4934,33 @@ system and gives an overview of their function and contents.
       ``OVERRIDES`` represents the "state" during building, which includes
       the current recipe being built, the machine for which it is being
       built, and so forth.
-   
+
       As an example, if the string "an-override" appears as an element in
       the colon-separated list in ``OVERRIDES``, then the following
       assignment will override ``FOO`` with the value "overridden" at the
-      end of parsing: FOO_an-override = "overridden" See the
+      end of parsing:
+      ::
+
+         FOO_an-override = "overridden"
+
+      See the
       ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`"
       section in the BitBake User Manual for more information on the
       overrides mechanism.
-   
+
       The default value of ``OVERRIDES`` includes the values of the
       :term:`CLASSOVERRIDE`,
       :term:`MACHINEOVERRIDES`, and
       :term:`DISTROOVERRIDES` variables. Another
       important override included by default is ``pn-${PN}``. This override
       allows variables to be set for a single recipe within configuration
-      (``.conf``) files. Here is an example: FOO_pn-myrecipe =
-      "myrecipe-specific value"
-   
+      (``.conf``) files. Here is an example:
+      ::
+
+         FOO_pn-myrecipe = "myrecipe-specific value"
+
       .. note::
-   
+
          An easy way to see what overrides apply is to search for
          OVERRIDES
          in the output of the
@@ -4438,128 +4969,134 @@ system and gives an overview of their function and contents.
          Viewing Variable Values
          " section in the Yocto Project Development Tasks Manual for more
          information.
-   
+
    P
       The recipe name and version. ``P`` is comprised of the following:
-      ${PN}-${PV}
-   
+      ::
+
+         ${PN}-${PV}
+
    PACKAGE_ADD_METADATA
       This variable defines additional metdata to add to packages.
-   
+
       You may find you need to inject additional metadata into packages.
       This variable allows you to do that by setting the injected data as
       the value. Multiple fields can be added by splitting the content with
       the literal separator "\n".
-   
+
       The suffixes '_IPK', '_DEB', or '_RPM' can be applied to the variable
       to do package type specific settings. It can also be made package
       specific by using the package name as a suffix.
-   
-      You can find out more about applying this variable in the "`Adding
-      custom metadata to
-      packages <&YOCTO_DOCS_DEV_URL;#adding-custom-metadata-to-packages>`__"
+
+      You can find out more about applying this variable in the
+      ":ref:`dev-manual/dev-manual-common-tasks:adding custom metadata to packages`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGE_ARCH
       The architecture of the resulting package or packages.
-   
+
       By default, the value of this variable is set to
       :term:`TUNE_PKGARCH` when building for the
       target, :term:`BUILD_ARCH` when building for the
       build host, and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building for the
       SDK.
-   
+
       .. note::
-   
+
          See
          SDK_ARCH
          for more information.
-   
+
       However, if your recipe's output packages are built specific to the
       target machine rather than generally for the architecture of the
       machine, you should set ``PACKAGE_ARCH`` to the value of
       :term:`MACHINE_ARCH` in the recipe as follows:
-      PACKAGE_ARCH = "${MACHINE_ARCH}"
-   
+      ::
+
+         PACKAGE_ARCH = "${MACHINE_ARCH}"
+
    PACKAGE_ARCHS
       Specifies a list of architectures compatible with the target machine.
       This variable is set automatically and should not normally be
       hand-edited. Entries are separated using spaces and listed in order
       of priority. The default value for ``PACKAGE_ARCHS`` is "all any
       noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}".
-   
+
    PACKAGE_BEFORE_PN
       Enables easily adding packages to ``PACKAGES`` before ``${PN}`` so
       that those added packages can pick up files that would normally be
       included in the default package.
-   
+
    PACKAGE_CLASSES
       This variable, which is set in the ``local.conf`` configuration file
       found in the ``conf`` folder of the
       :term:`Build Directory`, specifies the package manager the
       OpenEmbedded build system uses when packaging data.
-   
+
       You can provide one or more of the following arguments for the
       variable: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk
       package_tar"
-   
+
       .. note::
-   
+
          While it is a legal option, the
          package_tar
          class has limited functionality due to no support for package
          dependencies by that backend. Therefore, it is recommended that
          you do not use it.
-   
+
       The build system uses only the first argument in the list as the
       package manager when creating your image or SDK. However, packages
       will be created using any additional packaging classes you specify.
       For example, if you use the following in your ``local.conf`` file:
-      PACKAGE_CLASSES ?= "package_ipk" The OpenEmbedded build system uses
+      ::
+
+         PACKAGE_CLASSES ?= "package_ipk"
+
+      The OpenEmbedded build system uses
       the IPK package manager to create your image or SDK.
-   
+
       For information on packaging and build performance effects as a
       result of the package manager in use, see the
       ":ref:`package.bbclass <ref-classes-package>`" section.
-   
+
    PACKAGE_DEBUG_SPLIT_STYLE
       Determines how to split up the binary and debug information when
       creating ``*-dbg`` packages to be used with the GNU Project Debugger
       (GDB).
-   
+
       With the ``PACKAGE_DEBUG_SPLIT_STYLE`` variable, you can control
       where debug information, which can include or exclude source files,
       is stored:
-   
+
       -  ".debug": Debug symbol files are placed next to the binary in a
          ``.debug`` directory on the target. For example, if a binary is
          installed into ``/bin``, the corresponding debug symbol files are
          installed in ``/bin/.debug``. Source files are placed in
          ``/usr/src/debug``.
-   
+
       -  "debug-file-directory": Debug symbol files are placed under
          ``/usr/lib/debug`` on the target, and separated by the path from
          where the binary is installed. For example, if a binary is
          installed in ``/bin``, the corresponding debug symbols are
          installed in ``/usr/lib/debug/bin``. Source files are placed in
          ``/usr/src/debug``.
-   
+
       -  "debug-without-src": The same behavior as ".debug" previously
          described with the exception that no source files are installed.
-   
+
       -  "debug-with-srcpkg": The same behavior as ".debug" previously
          described with the exception that all source files are placed in a
          separate ``*-src`` pkg. This is the default behavior.
-   
+
       You can find out more about debugging using GDB by reading the
-      "`Debugging With the GNU Project Debugger (GDB)
-      Remotely <&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug>`__" section
+      ":ref:`platdev-gdb-remotedebug`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGE_EXCLUDE_COMPLEMENTARY
       Prevents specific packages from being installed when you are
       installing complementary packages.
-   
+
       You might find that you want to prevent installing certain packages
       when you are installing complementary packages. For example, if you
       are using :term:`IMAGE_FEATURES` to install
@@ -4567,16 +5104,21 @@ system and gives an overview of their function and contents.
       particular multilib. If you find yourself in this situation, you can
       use the ``PACKAGE_EXCLUDE_COMPLEMENTARY`` variable to specify regular
       expressions to match the packages you want to exclude.
-   
+
    PACKAGE_EXCLUDE
       Lists packages that should not be installed into an image. For
-      example: PACKAGE_EXCLUDE = "package_name package_name package_name
-      ..."
-   
+      example:
+      ::
+
+         PACKAGE_EXCLUDE = "package_name package_name package_name ..."
+
       You can set this variable globally in your ``local.conf`` file or you
       can attach it to a specific image recipe by using the recipe name
-      override: PACKAGE_EXCLUDE_pn-target_image = "package_name"
-   
+      override:
+      ::
+
+         PACKAGE_EXCLUDE_pn-target_image = "package_name"
+
       If you choose to not install a package using this variable and some
       other package is dependent on it (i.e. listed in a recipe's
       :term:`RDEPENDS` variable), the OpenEmbedded build
@@ -4584,19 +5126,19 @@ system and gives an overview of their function and contents.
       halts the process with a fatal error, you can use the variable with
       an iterative development process to remove specific components from a
       system.
-   
+
       Support for this variable exists only when using the IPK and RPM
       packaging backend. Support does not exist for DEB.
-   
+
       See the :term:`NO_RECOMMENDATIONS` and the
       :term:`BAD_RECOMMENDATIONS` variables for
       related information.
-   
+
    PACKAGE_EXTRA_ARCHS
       Specifies the list of architectures compatible with the device CPU.
       This variable is useful when you build for several different devices
       that use miscellaneous processors such as XScale and ARM926-EJS.
-   
+
    PACKAGE_FEED_ARCHS
       Optionally specifies the package architectures used as part of the
       package feed URIs during the build. When used, the
@@ -4605,9 +5147,9 @@ system and gives an overview of their function and contents.
       :term:`PACKAGE_FEED_URIS` and
       :term:`PACKAGE_FEED_BASE_PATHS`
       variables.
-   
+
       .. note::
-   
+
          You can use the
          PACKAGE_FEEDS_ARCHS
          variable to whitelist specific package architectures. If you do
@@ -4615,73 +5157,91 @@ system and gives an overview of their function and contents.
          case, you can omit this variable. Omitting the variable results in
          all available architectures for the current machine being included
          into remote package feeds.
-   
+
       Consider the following example where the ``PACKAGE_FEED_URIS``,
       ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are
-      defined in your ``local.conf`` file: PACKAGE_FEED_URIS =
-      "https://example.com/packagerepos/release \\
-      https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS =
-      "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these
-      settings, the resulting package feeds are as follows:
-      https://example.com/packagerepos/release/rpm/all
-      https://example.com/packagerepos/release/rpm/core2-64
-      https://example.com/packagerepos/release/rpm-dev/all
-      https://example.com/packagerepos/release/rpm-dev/core2-64
-      https://example.com/packagerepos/updates/rpm/all
-      https://example.com/packagerepos/updates/rpm/core2-64
-      https://example.com/packagerepos/updates/rpm-dev/all
-      https://example.com/packagerepos/updates/rpm-dev/core2-64
-   
+      defined in your ``local.conf`` file:
+      ::
+
+         PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                              https://example.com/packagerepos/updates"
+         PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+         PACKAGE_FEED_ARCHS = "all core2-64"
+
+      Given these settings, the resulting package feeds are as follows:
+      ::
+
+         https://example.com/packagerepos/release/rpm/all
+         https://example.com/packagerepos/release/rpm/core2-64
+         https://example.com/packagerepos/release/rpm-dev/all
+         https://example.com/packagerepos/release/rpm-dev/core2-64
+         https://example.com/packagerepos/updates/rpm/all
+         https://example.com/packagerepos/updates/rpm/core2-64
+         https://example.com/packagerepos/updates/rpm-dev/all
+         https://example.com/packagerepos/updates/rpm-dev/core2-64
+
    PACKAGE_FEED_BASE_PATHS
       Specifies the base path used when constructing package feed URIs. The
       ``PACKAGE_FEED_BASE_PATHS`` variable makes up the middle portion of a
       package feed URI used by the OpenEmbedded build system. The base path
       lies between the :term:`PACKAGE_FEED_URIS`
       and :term:`PACKAGE_FEED_ARCHS` variables.
-   
+
       Consider the following example where the ``PACKAGE_FEED_URIS``,
       ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are
-      defined in your ``local.conf`` file: PACKAGE_FEED_URIS =
-      "https://example.com/packagerepos/release \\
-      https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS =
-      "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these
-      settings, the resulting package feeds are as follows:
-      https://example.com/packagerepos/release/rpm/all
-      https://example.com/packagerepos/release/rpm/core2-64
-      https://example.com/packagerepos/release/rpm-dev/all
-      https://example.com/packagerepos/release/rpm-dev/core2-64
-      https://example.com/packagerepos/updates/rpm/all
-      https://example.com/packagerepos/updates/rpm/core2-64
-      https://example.com/packagerepos/updates/rpm-dev/all
-      https://example.com/packagerepos/updates/rpm-dev/core2-64
-   
+      defined in your ``local.conf`` file:
+      ::
+
+         PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                              https://example.com/packagerepos/updates"
+         PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+         PACKAGE_FEED_ARCHS = "all core2-64"
+
+      Given these settings, the resulting package feeds are as follows:
+      ::
+
+         https://example.com/packagerepos/release/rpm/all
+         https://example.com/packagerepos/release/rpm/core2-64
+         https://example.com/packagerepos/release/rpm-dev/all
+         https://example.com/packagerepos/release/rpm-dev/core2-64
+         https://example.com/packagerepos/updates/rpm/all
+         https://example.com/packagerepos/updates/rpm/core2-64
+         https://example.com/packagerepos/updates/rpm-dev/all
+         https://example.com/packagerepos/updates/rpm-dev/core2-64
+
    PACKAGE_FEED_URIS
       Specifies the front portion of the package feed URI used by the
       OpenEmbedded build system. Each final package feed URI is comprised
       of ``PACKAGE_FEED_URIS``,
       :term:`PACKAGE_FEED_BASE_PATHS`, and
       :term:`PACKAGE_FEED_ARCHS` variables.
-   
+
       Consider the following example where the ``PACKAGE_FEED_URIS``,
       ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are
-      defined in your ``local.conf`` file: PACKAGE_FEED_URIS =
-      "https://example.com/packagerepos/release \\
-      https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS =
-      "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these
-      settings, the resulting package feeds are as follows:
-      https://example.com/packagerepos/release/rpm/all
-      https://example.com/packagerepos/release/rpm/core2-64
-      https://example.com/packagerepos/release/rpm-dev/all
-      https://example.com/packagerepos/release/rpm-dev/core2-64
-      https://example.com/packagerepos/updates/rpm/all
-      https://example.com/packagerepos/updates/rpm/core2-64
-      https://example.com/packagerepos/updates/rpm-dev/all
-      https://example.com/packagerepos/updates/rpm-dev/core2-64
-   
+      defined in your ``local.conf`` file:
+      ::
+
+         PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                              https://example.com/packagerepos/updates"
+         PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+         PACKAGE_FEED_ARCHS = "all core2-64"
+
+      Given these settings, the resulting package feeds are as follows:
+      ::
+
+         https://example.com/packagerepos/release/rpm/all
+         https://example.com/packagerepos/release/rpm/core2-64
+         https://example.com/packagerepos/release/rpm-dev/all
+         https://example.com/packagerepos/release/rpm-dev/core2-64
+         https://example.com/packagerepos/updates/rpm/all
+         https://example.com/packagerepos/updates/rpm/core2-64
+         https://example.com/packagerepos/updates/rpm-dev/all
+         https://example.com/packagerepos/updates/rpm-dev/core2-64
+
    PACKAGE_INSTALL
       The final list of packages passed to the package manager for
       installation into the image.
-   
+
       Because the package manager controls actual installation of all
       packages, the list of packages passed using ``PACKAGE_INSTALL`` is
       not the final list of packages that are actually installed. This
@@ -4693,21 +5253,20 @@ system and gives an overview of their function and contents.
       ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__
       image. When working with an initial RAM filesystem (initramfs) image,
       use the ``PACKAGE_INSTALL`` variable. For information on creating an
-      initramfs, see the "`Building an Initial RAM Filesystem (initramfs)
-      Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section
+      initramfs, see the ":ref:`building-an-initramfs-image`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGE_INSTALL_ATTEMPTONLY
       Specifies a list of packages the OpenEmbedded build system attempts
       to install when creating an image. If a listed package fails to
       install, the build system does not generate an error. This variable
       is generally not user-defined.
-   
+
    PACKAGE_PREPROCESS_FUNCS
       Specifies a list of functions run to pre-process the
       :term:`PKGD` directory prior to splitting the files out
       to individual packages.
-   
+
    PACKAGE_WRITE_DEPS
       Specifies a list of dependencies for post-installation and
       pre-installation scripts on native/cross tools. If your
@@ -4715,93 +5274,114 @@ system and gives an overview of their function and contents.
       creation time rather than on the target but depends on a native tool
       in order to execute, you need to list the tools in
       ``PACKAGE_WRITE_DEPS``.
-   
+
       For information on running post-installation scripts, see the
-      "`Post-Installation
-      Scripts <&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGECONFIG
       This variable provides a means of enabling or disabling features of a
       recipe on a per-recipe basis. ``PACKAGECONFIG`` blocks are defined in
       recipes when you specify features and then arguments that define
       feature behaviors. Here is the basic block structure (broken over
-      multiple lines for readability): PACKAGECONFIG ??= "f1 f2 f3 ..."
-      PACKAGECONFIG[f1] = "\\ --with-f1, \\ --without-f1, \\
-      build-deps-for-f1, \\ runtime-deps-for-f1, \\
-      runtime-recommends-for-f1, \\ packageconfig-conflicts-for-f1 \\ "
-      PACKAGECONFIG[f2] = "\\ ... and so on and so on ...
-   
+      multiple lines for readability):
+      ::
+
+         PACKAGECONFIG ??= "f1 f2 f3 ..."
+         PACKAGECONFIG[f1] = "\
+             --with-f1, \
+             --without-f1, \
+             build-deps-for-f1, \
+             runtime-deps-for-f1, \
+             runtime-recommends-for-f1, \
+             packageconfig-conflicts-for-f1"
+         PACKAGECONFIG[f2] = "\
+              ... and so on and so on ...
+
       The ``PACKAGECONFIG`` variable itself specifies a space-separated
       list of the features to enable. Following the features, you can
       determine the behavior of each feature by providing up to six
       order-dependent arguments, which are separated by commas. You can
       omit any argument you like but must retain the separating commas. The
       order is important and specifies the following:
-   
+
       1. Extra arguments that should be added to the configure script
          argument list (:term:`EXTRA_OECONF` or
          :term:`PACKAGECONFIG_CONFARGS`) if
          the feature is enabled.
-   
+
       2. Extra arguments that should be added to ``EXTRA_OECONF`` or
          ``PACKAGECONFIG_CONFARGS`` if the feature is disabled.
-   
+
       3. Additional build dependencies (:term:`DEPENDS`)
          that should be added if the feature is enabled.
-   
+
       4. Additional runtime dependencies (:term:`RDEPENDS`)
          that should be added if the feature is enabled.
-   
+
       5. Additional runtime recommendations
          (:term:`RRECOMMENDS`) that should be added if
          the feature is enabled.
-   
+
       6. Any conflicting (that is, mutually exclusive) ``PACKAGECONFIG``
          settings for this feature.
-   
+
       Consider the following ``PACKAGECONFIG`` block taken from the
       ``librsvg`` recipe. In this example the feature is ``gtk``, which has
       three arguments that determine the feature's behavior.
-      PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3" The
+      ::
+
+         PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3"
+
+      The
       ``--with-gtk3`` and ``gtk+3`` arguments apply only if the feature is
       enabled. In this case, ``--with-gtk3`` is added to the configure
       script argument list and ``gtk+3`` is added to ``DEPENDS``. On the
       other hand, if the feature is disabled say through a ``.bbappend``
       file in another layer, then the second argument ``--without-gtk3`` is
       added to the configure script instead.
-   
+
       The basic ``PACKAGECONFIG`` structure previously described holds true
       regardless of whether you are creating a block or changing a block.
       When creating a block, use the structure inside your recipe.
-   
+
       If you want to change an existing ``PACKAGECONFIG`` block, you can do
       so one of two ways:
-   
+
       -  *Append file:* Create an append file named
          recipename\ ``.bbappend`` in your layer and override the value of
          ``PACKAGECONFIG``. You can either completely override the
-         variable: PACKAGECONFIG = "f4 f5" Or, you can just append the
-         variable: PACKAGECONFIG_append = " f4"
-   
+         variable:
+         ::
+
+            PACKAGECONFIG = "f4 f5"
+
+         Or, you can just append the variable:
+         ::
+
+            PACKAGECONFIG_append = " f4"
+
       -  *Configuration file:* This method is identical to changing the
          block through an append file except you edit your ``local.conf``
          or ``mydistro.conf`` file. As with append files previously
          described, you can either completely override the variable:
          PACKAGECONFIG_pn-recipename = "f4 f5" Or, you can just amend the
-         variable: PACKAGECONFIG_append_pn-recipename = " f4"
-   
+         variable:
+         ::
+
+            PACKAGECONFIG_append_pn-recipename = " f4"
+
    PACKAGECONFIG_CONFARGS
       A space-separated list of configuration options generated from the
       :term:`PACKAGECONFIG` setting.
-   
+
       Classes such as :ref:`autotools <ref-classes-autotools>` and
       :ref:`cmake <ref-classes-cmake>` use ``PACKAGECONFIG_CONFARGS`` to
       pass ``PACKAGECONFIG`` options to ``configure`` and ``cmake``,
       respectively. If you are using ``PACKAGECONFIG`` but not a class that
       handles the ``do_configure`` task, then you need to use
       ``PACKAGECONFIG_CONFARGS`` appropriately.
-   
+
    PACKAGEGROUP_DISABLE_COMPLEMENTARY
       For recipes inheriting the
       :ref:`packagegroup <ref-classes-packagegroup>` class, setting
@@ -4809,25 +5389,27 @@ system and gives an overview of their function and contents.
       normal complementary packages (i.e. ``-dev``, ``-dbg``, and so forth)
       should not be automatically created by the ``packagegroup`` recipe,
       which is the default behavior.
-   
+
    PACKAGES
       The list of packages the recipe creates. The default value is the
-      following: ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
-      ${PACKAGE_BEFORE_PN} ${PN}
-   
+      following:
+      ::
+
+         ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
+
       During packaging, the :ref:`ref-tasks-package` task
       goes through ``PACKAGES`` and uses the :term:`FILES`
       variable corresponding to each package to assign files to the
       package. If a file matches the ``FILES`` variable for more than one
       package in ``PACKAGES``, it will be assigned to the earliest
       (leftmost) package.
-   
+
       Packages in the variable's list that are empty (i.e. where none of
       the patterns in ``FILES_``\ pkg match any files installed by the
       :ref:`ref-tasks-install` task) are not generated,
       unless generation is forced through the
       :term:`ALLOW_EMPTY` variable.
-   
+
    PACKAGES_DYNAMIC
       A promise that your recipe satisfies runtime dependencies for
       optional modules that are found in other recipes.
@@ -4840,17 +5422,17 @@ system and gives an overview of their function and contents.
       to include that package in an image, you will get a dependency
       failure from the packaging system during the
       :ref:`ref-tasks-rootfs` task.
-   
+
       Typically, if there is a chance that such a situation can occur and
       the package that is not created is valid without the dependency being
       satisfied, then you should use :term:`RRECOMMENDS`
       (a soft runtime dependency) instead of ``RDEPENDS``.
-   
+
       For an example of how to use the ``PACKAGES_DYNAMIC`` variable when
-      you are splitting packages, see the "`Handling Optional Module
-      Packaging <&YOCTO_DOCS_DEV_URL;#handling-optional-module-packaging>`__"
+      you are splitting packages, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:handling optional module packaging`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGESPLITFUNCS
       Specifies a list of functions run to perform additional splitting of
       files into individual packages. Recipes can either prepend to this
@@ -4860,16 +5442,16 @@ system and gives an overview of their function and contents.
       :term:`FILES`, :term:`RDEPENDS` and
       other packaging variables appropriately in order to perform the
       desired splitting.
-   
+
    PARALLEL_MAKE
       Extra options passed to the ``make`` command during the
       :ref:`ref-tasks-compile` task in order to specify
       parallel compilation on the local build host. This variable is
       usually in the form "-j x", where x represents the maximum number of
       parallel threads ``make`` can run.
-   
+
       .. note::
-   
+
          In order for
          PARALLEL_MAKE
          to be effective,
@@ -4881,12 +5463,12 @@ system and gives an overview of their function and contents.
          . An easy way to ensure this is to use the
          oe_runmake
          function.
-   
+
       By default, the OpenEmbedded build system automatically sets this
       variable to be equal to the number of cores the build system uses.
-   
+
       .. note::
-   
+
          If the software being built experiences dependency issues during
          the
          do_compile
@@ -4896,50 +5478,49 @@ system and gives an overview of their function and contents.
          addressing race conditions, see the "
          Debugging Parallel Make Races
          " section in the Yocto Project Development Tasks Manual.
-   
+
       For single socket systems (i.e. one CPU), you should not have to
       override this variable to gain optimal parallelism during builds.
       However, if you have very large systems that employ multiple physical
       CPUs, you might want to make sure the ``PARALLEL_MAKE`` variable is
       not set higher than "-j 20".
-   
-      For more information on speeding up builds, see the "`Speeding Up a
-      Build <&YOCTO_DOCS_DEV_URL;#speeding-up-a-build>`__" section in the
-      Yocto Project Development Tasks Manual.
-   
+
+      For more information on speeding up builds, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+      section in the Yocto Project Development Tasks Manual.
+
    PARALLEL_MAKEINST
       Extra options passed to the ``make install`` command during the
       :ref:`ref-tasks-install` task in order to specify
       parallel installation. This variable defaults to the value of
       :term:`PARALLEL_MAKE`.
-   
+
       .. note::
-   
+
          In order for ``PARALLEL_MAKEINST`` to be effective, ``make`` must
          be called with
          ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy
          way to ensure this is to use the ``oe_runmake`` function.
-   
+
          If the software being built experiences dependency issues during
          the ``do_install`` task that result in race conditions, you can
          clear the ``PARALLEL_MAKEINST`` variable within the recipe as a
          workaround. For information on addressing race conditions, see the
-         "`Debugging Parallel Make
-         Races <&YOCTO_DOCS_DEV_URL;#debugging-parallel-make-races>`__"
+         ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
          section in the Yocto Project Development Tasks Manual.
-   
+
    PATCHRESOLVE
       Determines the action to take when a patch fails. You can set this
       variable to one of two values: "noop" and "user".
-   
+
       The default value of "noop" causes the build to simply fail when the
       OpenEmbedded build system cannot successfully apply a patch. Setting
       the value to "user" causes the build system to launch a shell and
       places you in the right location so that you can manually resolve the
       conflicts.
-   
+
       Set this variable in your ``local.conf`` file.
-   
+
    PATCHTOOL
       Specifies the utility used to apply patches for a recipe during the
       :ref:`ref-tasks-patch` task. You can specify one of
@@ -4947,24 +5528,28 @@ system and gives an overview of their function and contents.
       is "quilt" except for the quilt-native recipe itself. Because the
       quilt tool is not available at the time quilt-native is being
       patched, it uses "patch".
-   
+
       If you wish to use an alternative patching tool, set the variable in
-      the recipe using one of the following: PATCHTOOL = "patch" PATCHTOOL
-      = "quilt" PATCHTOOL = "git"
-   
+      the recipe using one of the following:
+      ::
+
+         PATCHTOOL = "patch"
+         PATCHTOOL = "quilt"
+         PATCHTOOL = "git"
+
    PE
       The epoch of the recipe. By default, this variable is unset. The
       variable is used to make upgrades possible when the versioning scheme
       changes in some backwards incompatible way.
-   
+
       ``PE`` is the default value of the :term:`PKGE` variable.
-   
+
    PF
       Specifies the recipe or package name and includes all version and
       revision numbers (i.e. ``glibc-2.13-r20+svnr15508/`` and
       ``bash-4.2-r1/``). This variable is comprised of the following:
       ${:term:`PN`}-${:term:`EXTENDPE`}${:term:`PV`}-${:term:`PR`}
-   
+
    PIXBUF_PACKAGES
       When inheriting the :ref:`pixbufcache <ref-classes-pixbufcache>`
       class, this variable identifies packages that contain the pixbuf
@@ -4972,139 +5557,158 @@ system and gives an overview of their function and contents.
       class assumes that the loaders are in the recipe's main package (i.e.
       ``${``\ :term:`PN`\ ``}``). Use this variable if the
       loaders you need are in a package other than that main package.
-   
+
    PKG
       The name of the resulting package created by the OpenEmbedded build
       system.
-   
+
       .. note::
-   
+
          When using the
          PKG
          variable, you must use a package name override.
-   
+
       For example, when the :ref:`debian <ref-classes-debian>` class
       renames the output package, it does so by setting
       ``PKG_packagename``.
-   
+
    PKG_CONFIG_PATH
       The path to ``pkg-config`` files for the current build context.
       ``pkg-config`` reads this variable from the environment.
-   
+
    PKGD
       Points to the destination directory for files to be packaged before
       they are split into individual packages. This directory defaults to
-      the following: ${WORKDIR}/package
-   
+      the following:
+      ::
+
+         ${WORKDIR}/package
+
       Do not change this default.
-   
+
    PKGDATA_DIR
       Points to a shared, global-state directory that holds data generated
       during the packaging process. During the packaging process, the
       :ref:`ref-tasks-packagedata` task packages data
       for each recipe and installs it into this temporary, shared area.
       This directory defaults to the following, which you should not
-      change: ${STAGING_DIR_HOST}/pkgdata For examples of how this data is
-      used, see the "`Automatically Added Runtime
-      Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+      change:
+      ::
+
+         ${STAGING_DIR_HOST}/pkgdata
+
+      For examples of how this data is used, see the
+      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual and the
-      "`Viewing Package Information with
-      ``oe-pkgdata-util`` <&YOCTO_DOCS_DEV_URL;#viewing-package-information-with-oe-pkgdata-util>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
       section in the Yocto Project Development Tasks Manual. For more
       information on the shared, global-state directory, see
       :term:`STAGING_DIR_HOST`.
-   
+
    PKGDEST
       Points to the parent directory for files to be packaged after they
       have been split into individual packages. This directory defaults to
-      the following: ${WORKDIR}/packages-split
-   
+      the following:
+      ::
+
+         ${WORKDIR}/packages-split
+
       Under this directory, the build system creates directories for each
       package specified in :term:`PACKAGES`. Do not change
       this default.
-   
+
    PKGDESTWORK
       Points to a temporary work area where the
       :ref:`ref-tasks-package` task saves package metadata.
       The ``PKGDESTWORK`` location defaults to the following:
-      ${WORKDIR}/pkgdata Do not change this default.
-   
+      ::
+
+         ${WORKDIR}/pkgdata
+
+      Do not change this default.
+
       The :ref:`ref-tasks-packagedata` task copies the
       package metadata from ``PKGDESTWORK`` to
       :term:`PKGDATA_DIR` to make it available globally.
-   
+
    PKGE
       The epoch of the package(s) built by the recipe. By default, ``PKGE``
       is set to :term:`PE`.
-   
+
    PKGR
       The revision of the package(s) built by the recipe. By default,
       ``PKGR`` is set to :term:`PR`.
-   
+
    PKGV
       The version of the package(s) built by the recipe. By default,
       ``PKGV`` is set to :term:`PV`.
-   
+
    PN
       This variable can have two separate functions depending on the
       context: a recipe name or a resulting package name.
-   
+
       ``PN`` refers to a recipe name in the context of a file used by the
       OpenEmbedded build system as input to create a package. The name is
       normally extracted from the recipe file name. For example, if the
       recipe is named ``expat_2.0.1.bb``, then the default value of ``PN``
       will be "expat".
-   
+
       The variable refers to a package name in the context of a file
       created or produced by the OpenEmbedded build system.
-   
+
       If applicable, the ``PN`` variable also contains any special suffix
       or prefix. For example, using ``bash`` to build packages for the
       native machine, ``PN`` is ``bash-native``. Using ``bash`` to build
       packages for the target and for Multilib, ``PN`` would be ``bash``
       and ``lib64-bash``, respectively.
-   
+
    PNBLACKLIST
       Lists recipes you do not want the OpenEmbedded build system to build.
       This variable works in conjunction with the
       :ref:`blacklist <ref-classes-blacklist>` class, which is inherited
       globally.
-   
+
       To prevent a recipe from being built, use the ``PNBLACKLIST``
       variable in your ``local.conf`` file. Here is an example that
-      prevents ``myrecipe`` from being built: PNBLACKLIST[myrecipe] = "Not
-      supported by our organization."
-   
+      prevents ``myrecipe`` from being built:
+      ::
+
+         PNBLACKLIST[myrecipe] = "Not supported by our organization."
+
    POPULATE_SDK_POST_HOST_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the host part of the SDK. You can specify
-      functions separated by semicolons: POPULATE_SDK_POST_HOST_COMMAND +=
-      "function; ... "
-   
+      functions separated by semicolons:
+      ::
+
+          POPULATE_SDK_POST_HOST_COMMAND += "function; ... "
+
       If you need to pass the SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
       the OpenEmbedded build system when creating SDK output. See the
       :term:`SDK_DIR` variable for more information.
-   
+
    POPULATE_SDK_POST_TARGET_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the target part of the SDK. You can specify
-      functions separated by semicolons: POPULATE_SDK_POST_TARGET_COMMAND
-      += "function; ... "
-   
+      functions separated by semicolons:
+      ::
+
+         POPULATE_SDK_POST_TARGET_COMMAND += "function; ... "
+
       If you need to pass the SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
       the OpenEmbedded build system when creating SDK output. See the
       :term:`SDK_DIR` variable for more information.
-   
+
    PR
       The revision of the recipe. The default value for this variable is
       "r0". Subsequent revisions of the recipe conventionally have the
       values "r1", "r2", and so forth. When :term:`PV` increases,
       ``PR`` is conventionally reset to "r0".
-   
+
       .. note::
-   
+
          The OpenEmbedded build system does not need the aid of
          PR
          to know when to rebuild a recipe. The build system uses the task
@@ -5114,7 +5718,7 @@ system and gives an overview of their function and contents.
          and
          shared state cache
          mechanisms.
-   
+
       The ``PR`` variable primarily becomes significant when a package
       manager dynamically installs packages on an already built image. In
       this case, ``PR``, which is the default value of
@@ -5124,37 +5728,45 @@ system and gives an overview of their function and contents.
       the same ``PV`` usually means that the packages all install the same
       upstream version, but with later (``PR``) version packages including
       packaging fixes.
-   
+
       .. note::
-   
+
          PR
          does not need to be increased for changes that do not change the
          package contents or metadata.
-   
+
       Because manually managing ``PR`` can be cumbersome and error-prone,
-      an automated solution exists. See the "`Working With a PR
-      Service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__" section
+      an automated solution exists. See the
+      ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`" section
       in the Yocto Project Development Tasks Manual for more information.
-   
+
    PREFERRED_PROVIDER
       If multiple recipes provide the same item, this variable determines
       which recipe is preferred and thus provides the item (i.e. the
       preferred provider). You should always suffix this variable with the
       name of the provided item. And, you should define the variable using
       the preferred recipe's name (:term:`PN`). Here is a common
-      example: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" In the
-      previous example, multiple recipes are providing "virtual/kernel".
+      example:
+      ::
+
+         PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+
+      In the previous example, multiple recipes are providing "virtual/kernel".
       The ``PREFERRED_PROVIDER`` variable is set with the name (``PN``) of
       the recipe you prefer to provide "virtual/kernel".
-   
-      Following are more examples: PREFERRED_PROVIDER_virtual/xserver =
-      "xserver-xf86" PREFERRED_PROVIDER_virtual/libgl ?= "mesa" For more
-      information, see the "`Using Virtual
-      Providers <&YOCTO_DOCS_DEV_URL;#metadata-virtual-providers>`__"
+
+      Following are more examples:
+      ::
+
+         PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
+         PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
+
+      For more
+      information, see the ":ref:`metadata-virtual-providers`"
       section in the Yocto Project Development Tasks Manual.
-   
+
       .. note::
-   
+
          If you use a
          virtual/\*
          item with
@@ -5166,56 +5778,69 @@ system and gives an overview of their function and contents.
          is prevented from building, which is usually desirable since this
          mechanism is designed to select between mutually exclusive
          alternative providers.
-   
+
    PREFERRED_VERSION
       If multiple versions of recipes exist, this variable determines which
       version is given preference. You must always suffix the variable with
       the :term:`PN` you want to select, and you should set the
       :term:`PV` accordingly for precedence.
-   
+
       The ``PREFERRED_VERSION`` variable supports limited wildcard use
       through the "``%``" character. You can use the character to match any
       number of characters, which can be useful when specifying versions
       that contain long revision numbers that potentially change. Here are
-      two examples: PREFERRED_VERSION_python = "3.4.0"
-      PREFERRED_VERSION_linux-yocto = "5.0%"
-   
+      two examples:
+      ::
+
+         PREFERRED_VERSION_python = "3.4.0"
+         PREFERRED_VERSION_linux-yocto = "5.0%"
+
       .. note::
-   
-         The use of the "
-         %
-         " character is limited in that it only works at the end of the
+
+         The use of the "%" character is limited in that it only works at the end of the
          string. You cannot use the wildcard character in any other
          location of the string.
-   
+
       The specified version is matched against :term:`PV`, which
       does not necessarily match the version part of the recipe's filename.
       For example, consider two recipes ``foo_1.2.bb`` and ``foo_git.bb``
-      where ``foo_git.bb`` contains the following assignment: PV =
-      "1.1+git${SRCPV}" In this case, the correct way to select
+      where ``foo_git.bb`` contains the following assignment:
+      ::
+
+         PV = "1.1+git${SRCPV}"
+
+      In this case, the correct way to select
       ``foo_git.bb`` is by using an assignment such as the following:
-      PREFERRED_VERSION_foo = "1.1+git%" Compare that previous example
+      ::
+
+         PREFERRED_VERSION_foo = "1.1+git%"
+
+      Compare that previous example
       against the following incorrect example, which does not work:
-      PREFERRED_VERSION_foo = "git"
-   
+      ::
+
+         PREFERRED_VERSION_foo = "git"
+
       Sometimes the ``PREFERRED_VERSION`` variable can be set by
       configuration files in a way that is hard to change. You can use
       :term:`OVERRIDES` to set a machine-specific
-      override. Here is an example: PREFERRED_VERSION_linux-yocto_qemux86 =
-      "5.0%" Although not recommended, worst case, you can also use the
+      override. Here is an example:
+      ::
+
+         PREFERRED_VERSION_linux-yocto_qemux86 = "5.0%"
+
+      Although not recommended, worst case, you can also use the
       "forcevariable" override, which is the strongest override possible.
-      Here is an example: PREFERRED_VERSION_linux-yocto_forcevariable =
-      "5.0%"
-   
+      Here is an example:
+      ::
+
+         PREFERRED_VERSION_linux-yocto_forcevariable = "5.0%"
+
       .. note::
-   
-         The
-         \_forcevariable
-         override is not handled specially. This override only works
-         because the default value of
-         OVERRIDES
-         includes "forcevariable".
-   
+
+         The \_forcevariable override is not handled specially. This override
+         only works because the default value of OVERRIDES includes "forcevariable".
+
    PREMIRRORS
       Specifies additional paths from which the OpenEmbedded build system
       gets source code. When the build system searches for source code, it
@@ -5223,35 +5848,40 @@ system and gives an overview of their function and contents.
       build system tries locations defined by ``PREMIRRORS``, the upstream
       source, and then locations specified by
       :term:`MIRRORS` in that order.
-   
+
       Assuming your distribution (:term:`DISTRO`) is "poky",
       the default value for ``PREMIRRORS`` is defined in the
       ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
-   
+
       Typically, you could add a specific server for the build system to
       attempt before any others by adding something like the following to
       the ``local.conf`` configuration file in the
-      :term:`Build Directory`: PREMIRRORS_prepend = "\\
-      git://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\*
-      http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\*
-      http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\*
-      http://www.yoctoproject.org/sources/ \\n" These changes cause the
+      :term:`Build Directory`:
+      ::
+
+         PREMIRRORS_prepend = "\
+             git://.*/.* http://www.yoctoproject.org/sources/ \n \
+             ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+             http://.*/.* http://www.yoctoproject.org/sources/ \n \
+             https://.*/.* http://www.yoctoproject.org/sources/ \n"
+
+      These changes cause the
       build system to intercept Git, FTP, HTTP, and HTTPS requests and
       direct them to the ``http://`` sources mirror. You can use
       ``file://`` URLs to point to local directories or network shares as
       well.
-   
+
    PRIORITY
       Indicates the importance of a package.
-   
+
       ``PRIORITY`` is considered to be part of the distribution policy
       because the importance of any given recipe depends on the purpose for
       which the distribution is being produced. Thus, ``PRIORITY`` is not
       normally set within recipes.
-   
+
       You can set ``PRIORITY`` to "required", "standard", "extra", and
       "optional", which is the default.
-   
+
    PRIVATE_LIBS
       Specifies libraries installed within a recipe that should be ignored
       by the OpenEmbedded build system's shared library resolver. This
@@ -5261,16 +5891,23 @@ system and gives an overview of their function and contents.
       private libraries to be set as a dependency on other unrelated
       packages that should instead depend on the package providing the
       standard version of the library.
-   
+
       Libraries specified in this variable should be specified by their
       file name. For example, from the Firefox recipe in meta-browser:
-      PRIVATE_LIBS = "libmozjs.so \\ libxpcom.so \\ libnspr4.so \\
-      libxul.so \\ libmozalloc.so \\ libplc4.so \\ libplds4.so"
-   
-      For more information, see the "`Automatically Added Runtime
-      Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+      ::
+
+         PRIVATE_LIBS = "libmozjs.so \
+                         libxpcom.so \
+                         libnspr4.so \
+                         libxul.so \
+                         libmozalloc.so \
+                         libplc4.so \
+                         libplds4.so"
+
+      For more information, see the
+      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual.
-   
+
    PROVIDES
       A list of aliases by which a particular recipe can be known. By
       default, a recipe's own ``PN`` is implicitly already in its
@@ -5279,13 +5916,18 @@ system and gives an overview of their function and contents.
       aliases are synonyms for the recipe and can be useful for satisfying
       dependencies of other recipes during the build as specified by
       ``DEPENDS``.
-   
+
       Consider the following example ``PROVIDES`` statement from the recipe
-      file ``eudev_3.2.9.bb``: PROVIDES = "udev" The ``PROVIDES`` statement
+      file ``eudev_3.2.9.bb``:
+      ::
+
+         PROVIDES = "udev"
+
+      The ``PROVIDES`` statement
       results in the "eudev" recipe also being available as simply "udev".
-   
+
       .. note::
-   
+
          Given that a recipe's own recipe name is already implicitly in its
          own
          PROVIDES
@@ -5293,12 +5935,12 @@ system and gives an overview of their function and contents.
          using a simple assignment will be sufficient. In other words,
          while you could write:
          ::
-   
+
                  PROVIDES += "udev"
-                                    
-   
+
+
          in the above, the "+=" is overkill and unnecessary.
-   
+
       In addition to providing recipes under alternate names, the
       ``PROVIDES`` mechanism is also used to implement virtual targets. A
       virtual target is a name that corresponds to some particular
@@ -5306,48 +5948,52 @@ system and gives an overview of their function and contents.
       functionality in question list the virtual target in ``PROVIDES``.
       Recipes that depend on the functionality in question can include the
       virtual target in ``DEPENDS`` to leave the choice of provider open.
-   
+
       Conventionally, virtual targets have names on the form
       "virtual/function" (e.g. "virtual/kernel"). The slash is simply part
       of the name and has no syntactical significance.
-   
+
       The :term:`PREFERRED_PROVIDER` variable is
       used to select which particular recipe provides a virtual target.
-   
+
       .. note::
-   
+
          A corresponding mechanism for virtual runtime dependencies
          (packages) exists. However, the mechanism does not depend on any
          special functionality beyond ordinary variable assignments. For
          example, ``VIRTUAL-RUNTIME_dev_manager`` refers to the package of
          the component that manages the ``/dev`` directory.
-   
+
          Setting the "preferred provider" for runtime dependencies is as
          simple as using the following assignment in a configuration file:
-   
          ::
-   
+
                  VIRTUAL-RUNTIME_dev_manager = "udev"
-                                    
-   
+
+
    PRSERV_HOST
       The network based :term:`PR` service host and port.
-   
+
       The ``conf/local.conf.sample.extended`` configuration file in the
       :term:`Source Directory` shows how the
-      ``PRSERV_HOST`` variable is set: PRSERV_HOST = "localhost:0" You must
-      set the variable if you want to automatically start a local `PR
-      service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__. You can
+      ``PRSERV_HOST`` variable is set:
+      ::
+
+         PRSERV_HOST = "localhost:0"
+
+      You must
+      set the variable if you want to automatically start a local :ref:`PR
+      service <dev-manual/dev-manual-common-tasks:working with a pr service>`. You can
       set ``PRSERV_HOST`` to other values to use a remote PR service.
-   
+
    PTEST_ENABLED
-      Specifies whether or not `Package
-      Test <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__ (ptest)
+      Specifies whether or not :ref:`Package
+      Test <dev-manual/dev-manual-common-tasks:testing packages with ptest>` (ptest)
       functionality is enabled when building a recipe. You should not set
       this variable directly. Enabling and disabling building Package Tests
       at build time should be done by adding "ptest" to (or removing it
       from) :term:`DISTRO_FEATURES`.
-   
+
    PV
       The version of the recipe. The version is normally extracted from the
       recipe filename. For example, if the recipe is named
@@ -5355,9 +6001,9 @@ system and gives an overview of their function and contents.
       ``PV`` is generally not overridden within a recipe unless it is
       building an unstable (i.e. development) version from a source code
       repository (e.g. Git or Subversion).
-   
+
       ``PV`` is the default value of the :term:`PKGV` variable.
-   
+
    PYTHON_ABI
       When used by recipes that inherit the
       :ref:`distutils3 <ref-classes-distutils3>`,
@@ -5367,15 +6013,15 @@ system and gives an overview of their function and contents.
       Application Binary Interface (ABI) currently in use for Python. By
       default, the ABI is "m". You do not have to set this variable as the
       OpenEmbedded build system sets it for you.
-   
+
       The OpenEmbedded build system uses the ABI to construct directory
       names used when installing the Python headers and libraries in
       sysroot (e.g. ``.../python3.3m/...``).
-   
+
       Recipes that inherit the ``distutils`` class during cross-builds also
       use this variable to locate the headers and libraries of the
       appropriate Python that the extension is targeting.
-   
+
    PYTHON_PN
       When used by recipes that inherit the
       `distutils3 <ref-classes-distutils3>`,
@@ -5385,43 +6031,62 @@ system and gives an overview of their function and contents.
       major Python version being built. For Python 3.x, ``PYTHON_PN`` would
       be "python3". You do not have to set this variable as the
       OpenEmbedded build system automatically sets it for you.
-   
+
       The variable allows recipes to use common infrastructure such as the
-      following: DEPENDS += "${PYTHON_PN}-native" In the previous example,
+      following:
+      ::
+
+         DEPENDS += "${PYTHON_PN}-native"
+
+      In the previous example,
       the version of the dependency is ``PYTHON_PN``.
-   
+
    RANLIB
       The minimal command and arguments to run ``ranlib``.
-   
+
    RCONFLICTS
       The list of packages that conflict with packages. Note that packages
       will not be installed if conflicting packages are not first removed.
-   
+
       Like all package-controlling variables, you must always use them in
       conjunction with a package name override. Here is an example:
-      RCONFLICTS_${PN} = "another_conflicting_package_name"
-   
+      ::
+
+         RCONFLICTS_${PN} = "another_conflicting_package_name"
+
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned dependencies. Although the syntax varies
       depending on the packaging format, BitBake hides these differences
       from you. Here is the general syntax to specify versions with the
-      ``RCONFLICTS`` variable: RCONFLICTS_${PN} = "package (operator
-      version)" For ``operator``, you can specify the following: = < > <=
+      ``RCONFLICTS`` variable:
+      ::
+
+         RCONFLICTS_${PN} = "package (operator version)"
+
+      For ``operator``, you can specify the following: = < > <=
       >= For example, the following sets up a dependency on version 1.2 or
-      greater of the package ``foo``: RCONFLICTS_${PN} = "foo (>= 1.2)"
-   
+      greater of the package ``foo``:
+      ::
+
+         RCONFLICTS_${PN} = "foo (>= 1.2)"
+
    RDEPENDS
       Lists runtime dependencies of a package. These dependencies are other
       packages that must be installed in order for the package to function
       correctly. As an example, the following assignment declares that the
       package ``foo`` needs the packages ``bar`` and ``baz`` to be
-      installed: RDEPENDS_foo = "bar baz" The most common types of package
+      installed:
+      ::
+
+         RDEPENDS_foo = "bar baz"
+
+      The most common types of package
       runtime dependencies are automatically detected and added. Therefore,
       most recipes do not need to set ``RDEPENDS``. For more information,
-      see the "`Automatically Added Runtime
-      Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+      see the
+      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual.
-   
+
       The practical effect of the above ``RDEPENDS`` assignment is that
       ``bar`` and ``baz`` will be declared as dependencies inside the
       package ``foo`` when it is written out by one of the
@@ -5431,7 +6096,7 @@ system and gives an overview of their function and contents.
       :term:`PACKAGE_CLASSES`. When the
       corresponding package manager installs the package, it will know to
       also install the packages on which it depends.
-   
+
       To ensure that the packages ``bar`` and ``baz`` get built, the
       previous ``RDEPENDS`` assignment also causes a task dependency to be
       added. This dependency is from the recipe's
@@ -5439,26 +6104,31 @@ system and gives an overview of their function and contents.
       :ref:`ref-tasks-compile`) task to the
       ``do_package_write_*`` task of the recipes that build ``bar`` and
       ``baz``.
-   
+
       The names of the packages you list within ``RDEPENDS`` must be the
       names of other packages - they cannot be recipe names. Although
       package names and recipe names usually match, the important point
       here is that you are providing package names within the ``RDEPENDS``
       variable. For an example of the default list of packages created from
       a recipe, see the :term:`PACKAGES` variable.
-   
+
       Because the ``RDEPENDS`` variable applies to packages being built,
       you should always use the variable in a form with an attached package
       name (remember that a single recipe can build multiple packages). For
       example, suppose you are building a development package that depends
       on the ``perl`` package. In this case, you would use the following
-      ``RDEPENDS`` statement: RDEPENDS_${PN}-dev += "perl" In the example,
+      ``RDEPENDS`` statement:
+      ::
+
+         RDEPENDS_${PN}-dev += "perl"
+
+      In the example,
       the development package depends on the ``perl`` package. Thus, the
       ``RDEPENDS`` variable has the ``${PN}-dev`` package name as part of
       the variable.
-   
+
       .. note::
-   
+
          RDEPENDS_${PN}-dev
          includes
          ${
@@ -5472,7 +6142,7 @@ system and gives an overview of their function and contents.
          when modifying
          RDEPENDS_${PN}-dev
          . Use the "+=" operator rather than the "=" operator.
-   
+
       The package names you use with ``RDEPENDS`` must appear as they would
       in the ``PACKAGES`` variable. The :term:`PKG` variable
       allows a different name to be used for the final package (e.g. the
@@ -5480,31 +6150,38 @@ system and gives an overview of their function and contents.
       packages), but this final package name cannot be used with
       ``RDEPENDS``, which makes sense as ``RDEPENDS`` is meant to be
       independent of the package format used.
-   
+
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned dependencies. Although the syntax varies
       depending on the packaging format, BitBake hides these differences
       from you. Here is the general syntax to specify versions with the
-      ``RDEPENDS`` variable: RDEPENDS_${PN} = "package (operator version)"
+      ``RDEPENDS`` variable:
+      ::
+
+         RDEPENDS_${PN} = "package (operator version)"
+
       For operator, you can specify the following: = < > <= >= For version,
       provide the version number.
-   
+
       .. note::
-   
+
          You can use
          EXTENDPKGV
          to provide a full package version specification.
-   
+
       For example, the following sets up a dependency on version 1.2 or
-      greater of the package ``foo``: RDEPENDS_${PN} = "foo (>= 1.2)"
-   
+      greater of the package ``foo``:
+      ::
+
+         RDEPENDS_${PN} = "foo (>= 1.2)"
+
       For information on build-time dependencies, see the
       :term:`DEPENDS` variable. You can also see the
       ":ref:`Tasks <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks>`" and
       ":ref:`Dependencies <bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies>`" sections in the
       BitBake User Manual for additional information on tasks and
       dependencies.
-   
+
    REQUIRED_DISTRO_FEATURES
       When inheriting the
       :ref:`distro_features_check <ref-classes-distro_features_check>`
@@ -5514,115 +6191,136 @@ system and gives an overview of their function and contents.
       ``REQUIRED_DISTRO_FEATURES`` variable lists a feature that does not
       appear in ``DISTRO_FEATURES`` within the current configuration, an
       error occurs and the build stops.
-   
+
    RM_WORK_EXCLUDE
       With ``rm_work`` enabled, this variable specifies a list of recipes
       whose work directories should not be removed. See the
       ":ref:`rm_work.bbclass <ref-classes-rm-work>`" section for more
       details.
-   
+
    ROOT_HOME
       Defines the root home directory. By default, this directory is set as
-      follows in the BitBake configuration file: ROOT_HOME ??= "/home/root"
-   
+      follows in the BitBake configuration file:
+      ::
+
+         ROOT_HOME ??= "/home/root"
+
       .. note::
-   
+
          This default value is likely used because some embedded solutions
          prefer to have a read-only root filesystem and prefer to keep
          writeable data in one place.
-   
+
       You can override the default by setting the variable in any layer or
       in the ``local.conf`` file. Because the default is set using a "weak"
       assignment (i.e. "??="), you can use either of the following forms to
-      define your override: ROOT_HOME = "/root" ROOT_HOME ?= "/root" These
+      define your override:
+      ::
+
+         ROOT_HOME = "/root"
+         ROOT_HOME ?= "/root"
+
+      These
       override examples use ``/root``, which is probably the most commonly
       used override.
-   
+
    ROOTFS
       Indicates a filesystem image to include as the root filesystem.
-   
+
       The ``ROOTFS`` variable is an optional variable used with the
       :ref:`image-live <ref-classes-image-live>` class.
-   
+
    ROOTFS_POSTINSTALL_COMMAND
       Specifies a list of functions to call after the OpenEmbedded build
       system has installed packages. You can specify functions separated by
-      semicolons: ROOTFS_POSTINSTALL_COMMAND += "function; ... "
-   
+      semicolons:
+      ::
+
+         ROOTFS_POSTINSTALL_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    ROOTFS_POSTPROCESS_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the root filesystem. You can specify functions
-      separated by semicolons: ROOTFS_POSTPROCESS_COMMAND += "function; ...
-      "
-   
+      separated by semicolons:
+      ::
+
+         ROOTFS_POSTPROCESS_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    ROOTFS_POSTUNINSTALL_COMMAND
       Specifies a list of functions to call after the OpenEmbedded build
       system has removed unnecessary packages. When runtime package
       management is disabled in the image, several packages are removed
       including ``base-passwd``, ``shadow``, and ``update-alternatives``.
       You can specify functions separated by semicolons:
-      ROOTFS_POSTUNINSTALL_COMMAND += "function; ... "
-   
+      ::
+
+         ROOTFS_POSTUNINSTALL_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    ROOTFS_PREPROCESS_COMMAND
       Specifies a list of functions to call before the OpenEmbedded build
       system has created the root filesystem. You can specify functions
-      separated by semicolons: ROOTFS_PREPROCESS_COMMAND += "function; ...
-      "
-   
+      separated by semicolons:
+      ::
+
+         ROOTFS_PREPROCESS_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    RPROVIDES
       A list of package name aliases that a package also provides. These
       aliases are useful for satisfying runtime dependencies of other
       packages both during the build and on the target (as specified by
       ``RDEPENDS``).
-   
+
       .. note::
-   
+
          A package's own name is implicitly already in its
          RPROVIDES
          list.
-   
+
       As with all package-controlling variables, you must always use the
       variable in conjunction with a package name override. Here is an
-      example: RPROVIDES_${PN} = "widget-abi-2"
-   
+      example:
+      ::
+
+         RPROVIDES_${PN} = "widget-abi-2"
+
    RRECOMMENDS
       A list of packages that extends the usability of a package being
       built. The package being built does not depend on this list of
       packages in order to successfully build, but rather uses them for
       extended usability. To specify runtime dependencies for packages, see
       the ``RDEPENDS`` variable.
-   
+
       The package manager will automatically install the ``RRECOMMENDS``
       list of packages when installing the built package. However, you can
       prevent listed packages from being installed by using the
       :term:`BAD_RECOMMENDATIONS`,
       :term:`NO_RECOMMENDATIONS`, and
       :term:`PACKAGE_EXCLUDE` variables.
-   
+
       Packages specified in ``RRECOMMENDS`` need not actually be produced.
       However, a recipe must exist that provides each package, either
       through the :term:`PACKAGES` or
@@ -5630,55 +6328,93 @@ system and gives an overview of their function and contents.
       :term:`RPROVIDES` variable, or an error will occur
       during the build. If such a recipe does exist and the package is not
       produced, the build continues without error.
-   
+
       Because the ``RRECOMMENDS`` variable applies to packages being built,
       you should always attach an override to the variable to specify the
       particular package whose usability is being extended. For example,
       suppose you are building a development package that is extended to
       support wireless functionality. In this case, you would use the
-      following: RRECOMMENDS_${PN}-dev += "wireless_package_name" In the
+      following:
+      ::
+
+         RRECOMMENDS_${PN}-dev += "wireless_package_name"
+
+      In the
       example, the package name (``${PN}-dev``) must appear as it would in
       the ``PACKAGES`` namespace before any renaming of the output package
       by classes such as ``debian.bbclass``.
-   
+
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned recommends. Although the syntax varies depending
       on the packaging format, BitBake hides these differences from you.
       Here is the general syntax to specify versions with the
-      ``RRECOMMENDS`` variable: RRECOMMENDS_${PN} = "package (operator
-      version)" For ``operator``, you can specify the following: = < > <=
-      >= For example, the following sets up a recommend on version 1.2 or
-      greater of the package ``foo``: RRECOMMENDS_${PN} = "foo (>= 1.2)"
-   
+      ``RRECOMMENDS`` variable:
+      ::
+
+         RRECOMMENDS_${PN} = "package (operator version)"
+
+      For ``operator``, you can specify the following:
+
+      - =
+      - <
+      - >
+      - <=
+      - >=
+
+      For example, the following sets up a recommend on version 1.2 or
+      greater of the package ``foo``:
+      ::
+
+         RRECOMMENDS_${PN} = "foo (>= 1.2)"
+
    RREPLACES
       A list of packages replaced by a package. The package manager uses
       this variable to determine which package should be installed to
       replace other package(s) during an upgrade. In order to also have the
       other package(s) removed at the same time, you must add the name of
       the other package to the ``RCONFLICTS`` variable.
-   
+
       As with all package-controlling variables, you must use this variable
       in conjunction with a package name override. Here is an example:
-      RREPLACES_${PN} = "other_package_being_replaced"
-   
+      ::
+
+         RREPLACES_${PN} = "other_package_being_replaced"
+
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned replacements. Although the syntax varies
       depending on the packaging format, BitBake hides these differences
       from you. Here is the general syntax to specify versions with the
-      ``RREPLACES`` variable: RREPLACES_${PN} = "package (operator
-      version)" For ``operator``, you can specify the following: = < > <=
-      >= For example, the following sets up a replacement using version 1.2
-      or greater of the package ``foo``: RREPLACES_${PN} = "foo (>= 1.2)"
-   
+      ``RREPLACES`` variable:
+      ::
+
+         RREPLACES_${PN} = "package (operator version)"
+
+      For ``operator``, you can specify the following:
+
+      - =
+      - <
+      - >
+      - <=
+      - >=
+
+      For example, the following sets up a replacement using version 1.2
+      or greater of the package ``foo``:
+      ::
+
+          RREPLACES_${PN} = "foo (>= 1.2)"
+
    RSUGGESTS
       A list of additional packages that you can suggest for installation
       by the package manager at the time a package is installed. Not all
       package managers support this functionality.
-   
+
       As with all package-controlling variables, you must always use this
       variable in conjunction with a package name override. Here is an
-      example: RSUGGESTS_${PN} = "useful_package another_package"
-   
+      example:
+      ::
+
+         RSUGGESTS_${PN} = "useful_package another_package"
+
    S
       The location in the :term:`Build Directory` where
       unpacked recipe source code resides. By default, this directory is
@@ -5689,27 +6425,33 @@ system and gives an overview of their function and contents.
       fetched from an SCM such as Git or Subversion, then you must set
       ``S`` in the recipe so that the OpenEmbedded build system knows where
       to find the unpacked source.
-   
+
       As an example, assume a :term:`Source Directory`
       top-level folder named ``poky`` and a default Build Directory at
       ``poky/build``. In this case, the work directory the build system
       uses to keep the unpacked recipe for ``db`` is the following:
-      poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19 The
-      unpacked source code resides in the ``db-5.1.19`` folder.
-   
+      ::
+
+         poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
+
+      The unpacked source code resides in the ``db-5.1.19`` folder.
+
       This next example assumes a Git repository. By default, Git
       repositories are cloned to ``${WORKDIR}/git`` during
       :ref:`ref-tasks-fetch`. Since this path is different
       from the default value of ``S``, you must set it specifically so the
-      source can be located: SRC_URI = "git://path/to/repo.git" S =
-      "${WORKDIR}/git"
-   
+      source can be located:
+      ::
+
+         SRC_URI = "git://path/to/repo.git"
+         S = "${WORKDIR}/git"
+
    SANITY_REQUIRED_UTILITIES
       Specifies a list of command-line utilities that should be checked for
       during the initial sanity checking process when running BitBake. If
       any of the utilities are not installed on the build host, then
       BitBake immediately exits with an error.
-   
+
    SANITY_TESTED_DISTROS
       A list of the host distribution identifiers that the build system has
       been tested against. Identifiers consist of the host distributor ID
@@ -5720,25 +6462,31 @@ system and gives an overview of their function and contents.
       :term:`NATIVELSBSTRING` does not appear in the
       list, then the build system reports a warning that indicates the
       current host distribution has not been tested as a build host.
-   
+
    SDK_ARCH
       The target architecture for the SDK. Typically, you do not directly
       set this variable. Instead, use :term:`SDKMACHINE`.
-   
+
    SDK_DEPLOY
       The directory set up and used by the
       :ref:`populate_sdk_base <ref-classes-populate-sdk>` class to which
       the SDK is deployed. The ``populate_sdk_base`` class defines
-      ``SDK_DEPLOY`` as follows: SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
-   
+      ``SDK_DEPLOY`` as follows:
+      ::
+
+         SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
+
    SDK_DIR
       The parent directory used by the OpenEmbedded build system when
       creating SDK output. The
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class defines
-      the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
-   
+      the variable as follows:
+      ::
+
+         SDK_DIR = "${WORKDIR}/sdk"
+
       .. note::
-   
+
          The
          SDK_DIR
          directory is a temporary directory as it is part of
@@ -5746,47 +6494,53 @@ system and gives an overview of their function and contents.
          . The final output directory is
          SDK_DEPLOY
          .
-   
+
    SDK_EXT_TYPE
       Controls whether or not shared state artifacts are copied into the
       extensible SDK. The default value of "full" copies all of the
       required shared state artifacts into the extensible SDK. The value
       "minimal" leaves these artifacts out of the SDK.
-   
+
       .. note::
-   
+
          If you set the variable to "minimal", you need to ensure
          SSTATE_MIRRORS
          is set in the SDK's configuration to enable the artifacts to be
          fetched as needed.
-   
+
    SDK_HOST_MANIFEST
       The manifest file for the host part of the SDK. This file lists all
       the installed packages that make up the host part of the SDK. The
       file contains package information on a line-per-package basis as
-      follows: packagename packagearch version
-   
+      follows:
+      ::
+
+         packagename packagearch version
+
       The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
-      defines the manifest file as follows: SDK_HOST_MANIFEST =
-      "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is
-      derived using the :term:`SDK_DEPLOY` and
+      defines the manifest file as follows:
+      ::
+
+         SDK_HOST_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest"
+
+      The location is derived using the :term:`SDK_DEPLOY` and
       :term:`TOOLCHAIN_OUTPUTNAME` variables.
-   
+
    SDK_INCLUDE_PKGDATA
       When set to "1", specifies to include the packagedata for all recipes
       in the "world" target in the extensible SDK. Including this data
       allows the ``devtool search`` command to find these recipes in search
       results, as well as allows the ``devtool add`` command to map
       dependencies more effectively.
-   
+
       .. note::
-   
+
          Enabling the
          SDK_INCLUDE_PKGDATA
          variable significantly increases build time because all of world
          needs to be built. Enabling the variable also slightly increases
          the size of the extensible SDK.
-   
+
    SDK_INCLUDE_TOOLCHAIN
       When set to "1", specifies to include the toolchain in the extensible
       SDK. Including the toolchain is useful particularly when
@@ -5795,375 +6549,417 @@ system and gives an overview of their function and contents.
       toolchain. For example, suppose you want to use the toolchain from an
       IDE or from other tools and you do not want to perform additional
       steps to install the toolchain.
-   
+
       The ``SDK_INCLUDE_TOOLCHAIN`` variable defaults to "0" if
       ``SDK_EXT_TYPE`` is set to "minimal", and defaults to "1" if
       ``SDK_EXT_TYPE`` is set to "full".
-   
+
    SDK_INHERIT_BLACKLIST
       A list of classes to remove from the :term:`INHERIT`
       value globally within the extensible SDK configuration. The
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class sets the
-      default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
-   
+      default value:
+      ::
+
+         SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
+
       Some classes are not generally applicable within the extensible SDK
       context. You can use this variable to disable those classes.
-   
+
       For additional information on how to customize the extensible SDK's
-      configuration, see the "`Configuring the Extensible
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__"
+      configuration, see the
+      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDK_LOCAL_CONF_BLACKLIST
       A list of variables not allowed through from the OpenEmbedded build
       system configuration into the extensible SDK configuration. Usually,
       these are variables that are specific to the machine on which the
       build system is running and thus would be potentially problematic
       within the extensible SDK.
-   
+
       By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class and
       excludes the following variables:
-      :term:`CONF_VERSION`
-      :term:`BB_NUMBER_THREADS`
-      :term:`bitbake:BB_NUMBER_PARSE_THREADS`
-      :term:`PARALLEL_MAKE`
-      :term:`PRSERV_HOST`
-      :term:`SSTATE_MIRRORS` :term:`DL_DIR`
-      :term:`SSTATE_DIR` :term:`TMPDIR`
-      :term:`BB_SERVER_TIMEOUT`
-   
+
+      - :term:`CONF_VERSION`
+      - :term:`BB_NUMBER_THREADS`
+      - :term:`bitbake:BB_NUMBER_PARSE_THREADS`
+      - :term:`PARALLEL_MAKE`
+      - :term:`PRSERV_HOST`
+      - :term:`SSTATE_MIRRORS` :term:`DL_DIR`
+      - :term:`SSTATE_DIR` :term:`TMPDIR`
+      - :term:`BB_SERVER_TIMEOUT`
+
       For additional information on how to customize the extensible SDK's
-      configuration, see the "`Configuring the Extensible
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__"
+      configuration, see the
+      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDK_LOCAL_CONF_WHITELIST
       A list of variables allowed through from the OpenEmbedded build
       system configuration into the extensible SDK configuration. By
       default, the list of variables is empty and is set in the
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
-   
+
       This list overrides the variables specified using the
       :term:`SDK_LOCAL_CONF_BLACKLIST`
       variable as well as any variables identified by automatic
       blacklisting due to the "/" character being found at the start of the
       value, which is usually indicative of being a path and thus might not
       be valid on the system where the SDK is installed.
-   
+
       For additional information on how to customize the extensible SDK's
-      configuration, see the "`Configuring the Extensible
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__"
+      configuration, see the
+      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDK_NAME
       The base name for SDK output files. The name is derived from the
       :term:`DISTRO`, :term:`TCLIBC`,
       :term:`SDK_ARCH`,
       :term:`IMAGE_BASENAME`, and
-      :term:`TUNE_PKGARCH` variables: SDK_NAME =
-      "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
-   
+      :term:`TUNE_PKGARCH` variables:
+      ::
+
+         SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
+
    SDK_OS
       Specifies the operating system for which the SDK will be built. The
       default value is the value of :term:`BUILD_OS`.
-   
+
    SDK_OUTPUT
       The location used by the OpenEmbedded build system when creating SDK
       output. The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
-      class defines the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
-      SDK_OUTPUT = "${SDK_DIR}/image" SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
-   
+      class defines the variable as follows:
+      ::
+
+         SDK_DIR = "${WORKDIR}/sdk"
+         SDK_OUTPUT = "${SDK_DIR}/image"
+         SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
+
       .. note::
-   
-         The
-         SDK_OUTPUT
-         directory is a temporary directory as it is part of
-         WORKDIR
-         by way of
-         SDK_DIR
-         . The final output directory is
-         SDK_DEPLOY
-         .
-   
+
+         The SDK_OUTPUT directory is a temporary directory as it is part of
+         WORKDIR by way of SDK_DIR. The final output directory is
+         SDK_DEPLOY.
+
    SDK_PACKAGE_ARCHS
       Specifies a list of architectures compatible with the SDK machine.
       This variable is set automatically and should not normally be
       hand-edited. Entries are separated using spaces and listed in order
       of priority. The default value for ``SDK_PACKAGE_ARCHS`` is "all any
       noarch ${SDK_ARCH}-${SDKPKGSUFFIX}".
-   
+
    SDK_POSTPROCESS_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system creates the SDK. You can specify functions separated by
       semicolons: SDK_POSTPROCESS_COMMAND += "function; ... "
-   
+
       If you need to pass an SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
       the OpenEmbedded build system when creating SDK output. See the
       :term:`SDK_DIR` variable for more information.
-   
+
    SDK_PREFIX
       The toolchain binary prefix used for ``nativesdk`` recipes. The
       OpenEmbedded build system uses the ``SDK_PREFIX`` value to set the
       :term:`TARGET_PREFIX` when building
       ``nativesdk`` recipes. The default value is "${SDK_SYS}-".
-   
+
    SDK_RECRDEP_TASKS
       A list of shared state tasks added to the extensible SDK. By default,
-      the following tasks are added: do_populate_lic do_package_qa
-      do_populate_sysroot do_deploy Despite the default value of "" for the
+      the following tasks are added:
+
+      - do_populate_lic
+      - do_package_qa
+      - do_populate_sysroot
+      - do_deploy
+
+      Despite the default value of "" for the
       ``SDK_RECRDEP_TASKS`` variable, the above four tasks are always added
       to the SDK. To specify tasks beyond these four, you need to use the
       ``SDK_RECRDEP_TASKS`` variable (e.g. you are defining additional
       tasks that are needed in order to build
       :term:`SDK_TARGETS`).
-   
+
    SDK_SYS
       Specifies the system, including the architecture and the operating
       system, for which the SDK will be built.
-   
+
       The OpenEmbedded build system automatically sets this variable based
       on :term:`SDK_ARCH`,
       :term:`SDK_VENDOR`, and
       :term:`SDK_OS`. You do not need to set the ``SDK_SYS``
       variable yourself.
-   
+
    SDK_TARGET_MANIFEST
       The manifest file for the target part of the SDK. This file lists all
       the installed packages that make up the target part of the SDK. The
       file contains package information on a line-per-package basis as
-      follows: packagename packagearch version
-   
+      follows:
+      ::
+
+         packagename packagearch version
+
       The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
-      defines the manifest file as follows: SDK_TARGET_MANIFEST =
-      "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location
-      is derived using the :term:`SDK_DEPLOY` and
+      defines the manifest file as follows:
+      ::
+
+         SDK_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest"
+
+      The location is derived using the :term:`SDK_DEPLOY` and
       :term:`TOOLCHAIN_OUTPUTNAME` variables.
-   
+
    SDK_TARGETS
       A list of targets to install from shared state as part of the
       standard or extensible SDK installation. The default value is "${PN}"
       (i.e. the image from which the SDK is built).
-   
+
       The ``SDK_TARGETS`` variable is an internal variable and typically
       would not be changed.
-   
+
    SDK_TITLE
       The title to be printed when running the SDK installer. By default,
       this title is based on the :term:`DISTRO_NAME` or
       :term:`DISTRO` variable and is set in the
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
-      follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or
-      d.getVar('DISTRO')} SDK" For the default distribution "poky",
+      follows:
+      ::
+
+         SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
+
+      For the default distribution "poky",
       ``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)".
-   
+
       For information on how to change this default title, see the
-      "`Changing the Extensible SDK Installer
-      Title <&YOCTO_DOCS_SDK_URL;#sdk-changing-the-sdk-installer-title>`__"
+      ":ref:`sdk-manual/sdk-appendix-customizing:changing the extensible sdk installer title`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDK_UPDATE_URL
       An optional URL for an update server for the extensible SDK. If set,
       the value is used as the default update server when running
       ``devtool sdk-update`` within the extensible SDK.
-   
+
    SDK_VENDOR
       Specifies the name of the SDK vendor.
-   
+
    SDK_VERSION
       Specifies the version of the SDK. The distribution configuration file
       (e.g. ``/meta-poky/conf/distro/poky.conf``) defines the
-      ``SDK_VERSION`` as follows: SDK_VERSION =
-      "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
-   
+      ``SDK_VERSION`` as follows:
+      ::
+
+         SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
+
       For additional information, see the
       :term:`DISTRO_VERSION` and
       :term:`DATE` variables.
-   
+
    SDKEXTPATH
       The default installation directory for the Extensible SDK. By
       default, this directory is based on the :term:`DISTRO`
       variable and is set in the
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
-      follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the
+      follows:
+      ::
+
+         SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk"
+
+      For the
       default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk".
-   
+
       For information on how to change this default directory, see the
-      "`Changing the Default SDK Installation
-      Directory <&YOCTO_DOCS_SDK_URL;#sdk-changing-the-default-sdk-installation-directory>`__"
+      ":ref:`sdk-manual/sdk-appendix-customizing:changing the default sdk installation directory`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDKIMAGE_FEATURES
       Equivalent to ``IMAGE_FEATURES``. However, this variable applies to
-      the SDK generated from an image using the following command: $
-      bitbake -c populate_sdk imagename
-   
+      the SDK generated from an image using the following command:
+      ::
+
+         $ bitbake -c populate_sdk imagename
+
    SDKMACHINE
       The machine for which the SDK is built. In other words, the SDK is
       built such that it runs on the target you specify with the
       ``SDKMACHINE`` value. The value points to a corresponding ``.conf``
       file under ``conf/machine-sdk/``.
-   
+
       You can use "i686" and "x86_64" as possible values for this variable.
       The variable defaults to "i686" and is set in the local.conf file in
-      the Build Directory. SDKMACHINE ?= "i686"
-   
+      the Build Directory.
+      ::
+
+         SDKMACHINE ?= "i686"
+
       .. note::
-   
+
          You cannot set the
          SDKMACHINE
          variable in your distribution configuration file. If you do, the
          configuration will not take affect.
-   
+
    SDKPATH
       Defines the path offered to the user for installation of the SDK that
       is generated by the OpenEmbedded build system. The path appears as
       the default location for installing the SDK when you run the SDK's
       installation script. You can override the offered path when you run
       the script.
-   
+
    SDKTARGETSYSROOT
       The full path to the sysroot used for cross-compilation within an SDK
       as it will be when installed into the default
       :term:`SDKPATH`.
-   
+
    SECTION
       The section in which packages should be categorized. Package
       management utilities can make use of this variable.
-   
+
    SELECTED_OPTIMIZATION
       Specifies the optimization flags passed to the C compiler when
       building for the target. The flags are passed through the default
       value of the :term:`TARGET_CFLAGS` variable.
-   
+
       The ``SELECTED_OPTIMIZATION`` variable takes the value of
       ``FULL_OPTIMIZATION`` unless ``DEBUG_BUILD`` = "1". If that is the
       case, the value of ``DEBUG_OPTIMIZATION`` is used.
-   
+
    SERIAL_CONSOLE
       Defines a serial console (TTY) to enable using
       `getty <https://en.wikipedia.org/wiki/Getty_(Unix)>`__. Provide a
       value that specifies the baud rate followed by the TTY device name
       separated by a space. You cannot specify more than one TTY device:
-      SERIAL_CONSOLE = "115200 ttyS0"
-   
+      ::
+
+         SERIAL_CONSOLE = "115200 ttyS0"
+
       .. note::
-   
+
          The
          SERIAL_CONSOLE
          variable is deprecated. Please use the
          SERIAL_CONSOLES
          variable.
-   
+
    SERIAL_CONSOLES
       Defines a serial console (TTY) to enable using
       `getty <https://en.wikipedia.org/wiki/Getty_(Unix)>`__. Provide a
       value that specifies the baud rate followed by the TTY device name
       separated by a semicolon. Use spaces to separate multiple devices:
-      SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
-   
+      ::
+
+         SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
+
    SERIAL_CONSOLES_CHECK
       Specifies serial consoles, which must be listed in
       :term:`SERIAL_CONSOLES`, to check against
       ``/proc/console`` before enabling them using getty. This variable
       allows aliasing in the format: <device>:<alias>. If a device was
       listed as "sclp_line0" in ``/dev/`` and "ttyS0" was listed in
-      ``/proc/console``, you would do the following: SERIAL_CONSOLES_CHECK
-      = "slcp_line0:ttyS0" This variable is currently only supported with
-      SysVinit (i.e. not with systemd).
-   
+      ``/proc/console``, you would do the following: ::
+
+         SERIAL_CONSOLES_CHECK = "slcp_line0:ttyS0"
+
+      This variable is currently only supported with SysVinit (i.e. not
+      with systemd).
+
    SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS
       A list of recipe dependencies that should not be used to determine
       signatures of tasks from one recipe when they depend on tasks from
-      another recipe. For example: SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS +=
-      "intone->mplayer2"
-   
+      another recipe. For example: ::
+
+         SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"
+
       In the previous example, ``intone`` depends on ``mplayer2``.
-   
+
       You can use the special token ``"*"`` on the left-hand side of the
       dependency to match all recipes except the one on the right-hand
-      side. Here is an example: SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS +=
-      "*->quilt-native"
-   
+      side. Here is an example: ::
+
+         SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native"
+
       In the previous example, all recipes except ``quilt-native`` ignore
       task signatures from the ``quilt-native`` recipe when determining
       their task signatures.
-   
+
       Use of this variable is one mechanism to remove dependencies that
       affect task signatures and thus force rebuilds when a recipe changes.
-   
+
       .. note::
-   
+
          If you add an inappropriate dependency for a recipe relationship,
          the software might break during runtime if the interface of the
          second recipe was changed after the first recipe had been built.
-   
+
    SIGGEN_EXCLUDERECIPES_ABISAFE
       A list of recipes that are completely stable and will never change.
       The ABI for the recipes in the list are presented by output from the
       tasks run to build the recipe. Use of this variable is one way to
       remove dependencies from one recipe on another that affect task
       signatures and thus force rebuilds when the recipe changes.
-   
+
       .. note::
-   
+
          If you add an inappropriate variable to this list, the software
          might break at runtime if the interface of the recipe was changed
          after the other had been built.
-   
+
    SITEINFO_BITS
       Specifies the number of bits for the target system CPU. The value
       should be either "32" or "64".
-   
+
    SITEINFO_ENDIANNESS
       Specifies the endian byte order of the target system. The value
       should be either "le" for little-endian or "be" for big-endian.
-   
+
    SKIP_FILEDEPS
       Enables removal of all files from the "Provides" section of an RPM
       package. Removal of these files is required for packages containing
       prebuilt binaries and libraries such as ``libstdc++`` and ``glibc``.
-   
+
       To enable file removal, set the variable to "1" in your
-      ``conf/local.conf`` configuration file in your: 
-      :term:`Build Directory`. SKIP_FILEDEPS = "1"
-   
+      ``conf/local.conf`` configuration file in your:
+      :term:`Build Directory`.
+      ::
+
+         SKIP_FILEDEPS = "1"
+
    SOC_FAMILY
       Groups together machines based upon the same family of SOC (System On
       Chip). You typically set this variable in a common ``.inc`` file that
       you include in the configuration files of all the machines.
-   
+
       .. note::
-   
+
          You must include
          conf/machine/include/soc-family.inc
          for this variable to appear in
          MACHINEOVERRIDES
          .
-   
+
    SOLIBS
       Defines the suffix for shared libraries used on the target platform.
       By default, this suffix is ".so.*" for all Linux-based systems and is
       defined in the ``meta/conf/bitbake.conf`` configuration file.
-   
+
       You will see this variable referenced in the default values of
       ``FILES_${PN}``.
-   
+
    SOLIBSDEV
       Defines the suffix for the development symbolic link (symlink) for
       shared libraries on the target platform. By default, this suffix is
       ".so" for Linux-based systems and is defined in the
       ``meta/conf/bitbake.conf`` configuration file.
-   
+
       You will see this variable referenced in the default values of
       ``FILES_${PN}-dev``.
-   
+
    SOURCE_MIRROR_FETCH
       When you are fetching files to create a mirror of sources (i.e.
       creating a source mirror), setting ``SOURCE_MIRROR_FETCH`` to "1" in
@@ -6175,69 +6971,75 @@ system and gives an overview of their function and contents.
       variable and :term:`COMPATIBLE_HOST` variables
       specify compatibility with a machine other than that of the current
       machine or host.
-   
+
       .. note::
-   
+
          Do not set the
          SOURCE_MIRROR_FETCH
          variable unless you are creating a source mirror. In other words,
          do not set the variable during a normal build.
-   
+
    SOURCE_MIRROR_URL
       Defines your own :term:`PREMIRRORS` from which to
       first fetch source before attempting to fetch from the upstream
       specified in :term:`SRC_URI`.
-   
+
       To use this variable, you must globally inherit the
       :ref:`own-mirrors <ref-classes-own-mirrors>` class and then provide
-      the URL to your mirrors. Here is the general syntax: INHERIT +=
-      "own-mirrors" SOURCE_MIRROR_URL =
-      "http://example.com/my_source_mirror"
-   
+      the URL to your mirrors. Here is the general syntax:
+      ::
+
+         INHERIT += "own-mirrors"
+         SOURCE_MIRROR_URL = "http://example.com/my_source_mirror"
+
       .. note::
-   
+
          You can specify only a single URL in
          SOURCE_MIRROR_URL
          .
-   
+
    SPDXLICENSEMAP
       Maps commonly used license names to their SPDX counterparts found in
       ``meta/files/common-licenses/``. For the default ``SPDXLICENSEMAP``
       mappings, see the ``meta/conf/licenses.conf`` file.
-   
+
       For additional information, see the :term:`LICENSE`
       variable.
-   
+
    SPECIAL_PKGSUFFIX
       A list of prefixes for :term:`PN` used by the OpenEmbedded
       build system to create variants of recipes or packages. The list
       specifies the prefixes to strip off during certain circumstances such
       as the generation of the :term:`BPN` variable.
-   
+
    SPL_BINARY
       The file type for the Secondary Program Loader (SPL). Some devices
       use an SPL from which to boot (e.g. the BeagleBone development
       board). For such cases, you can declare the file type of the SPL
       binary in the ``u-boot.inc`` include file, which is used in the
       U-Boot recipe.
-   
+
       The SPL file type is set to "null" by default in the ``u-boot.inc``
-      file as follows: # Some versions of u-boot build an SPL (Second
-      Program Loader) image that # should be packaged along with the u-boot
-      binary as well as placed in the # deploy directory. For those
-      versions they can set the following variables # to allow packaging
-      the SPL. SPL_BINARY ?= "" SPL_BINARYNAME ?=
-      "${@os.path.basename(d.getVar("SPL_BINARY"))}" SPL_IMAGE ?=
-      "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}" SPL_SYMLINK ?=
-      "${SPL_BINARYNAME}-${MACHINE}" The ``SPL_BINARY`` variable helps form
+      file as follows:
+      ::
+
+         # Some versions of u-boot build an SPL (Second Program Loader) image that
+         # should be packaged along with the u-boot binary as well as placed in the
+         # deploy directory. For those versions they can set the following variables
+         # to allow packaging the SPL.
+         SPL_BINARY ?= ""
+         SPL_BINARYNAME ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}"
+         SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}"
+         SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}"
+
+      The ``SPL_BINARY`` variable helps form
       various ``SPL_*`` variables used by the OpenEmbedded build system.
-   
-      See the BeagleBone machine configuration example in the "`Creating a
-      new BSP Layer Using the ``bitbake-layers``
-      Script <&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-bitbake-layers-script>`__"
+
+      See the BeagleBone machine configuration example in the
+      ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
       section in the Yocto Project Board Support Package Developer's Guide
       for additional information.
-   
+
    SRC_URI
       The list of source files - local or remote. This variable tells the
       OpenEmbedded build system which bits to pull in for the build and how
@@ -6247,34 +7049,34 @@ system and gives an overview of their function and contents.
       append file needs to fetch a tarball, apply two patches, and include
       a custom file, the recipe or append file would include four instances
       of the variable.
-   
+
       The following list explains the available URI protocols. URI
       protocols are highly dependent on particular BitBake Fetcher
       submodules. Depending on the fetcher BitBake uses, various URL
       parameters are employed. For specifics on the supported Fetchers, see
       the ":ref:`Fetchers <bitbake:bb-fetchers>`" section in the
       BitBake User Manual.
-   
-      -  *``file://`` -* Fetches files, which are usually files shipped
+
+      -  ``file://`` - Fetches files, which are usually files shipped
          with the :term:`Metadata`, from the local machine (e.g.
-         `patch <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__ files).
+         :ref:`patch <patching-dev-environment>` files).
          The path is relative to the :term:`FILESPATH`
          variable. Thus, the build system searches, in order, from the
          following directories, which are assumed to be a subdirectories of
          the directory in which the recipe file (``.bb``) or append file
          (``.bbappend``) resides:
-   
-         -  *``${BPN}`` -* The base recipe name without any special suffix
+
+         -  ``${BPN}`` - The base recipe name without any special suffix
             or version numbers.
-   
-         -  *``${BP}`` -* ``${BPN}-${PV}``. The base recipe name and
+
+         -  ``${BP}`` - ``${BPN}-${PV}``. The base recipe name and
             version but without any special package name suffix.
-   
+
          -  *files -* Files within a directory, which is named ``files``
             and is also alongside the recipe or append file.
-   
+
          .. note::
-   
+
             If you want the build system to pick up files specified through
             a
             SRC_URI
@@ -6284,127 +7086,133 @@ system and gives an overview of their function and contents.
             variable by also using the
             FILESEXTRAPATHS
             variable from within your append file.
-   
-      -  *``bzr://`` -* Fetches files from a Bazaar revision control
+
+      -  ``bzr://`` - Fetches files from a Bazaar revision control
          repository.
-   
-      -  *``git://`` -* Fetches files from a Git revision control
+
+      -  ``git://`` - Fetches files from a Git revision control
          repository.
-   
-      -  *``osc://`` -* Fetches files from an OSC (OpenSUSE Build service)
+
+      -  ``osc://`` - Fetches files from an OSC (OpenSUSE Build service)
          revision control repository.
-   
-      -  *``repo://`` -* Fetches files from a repo (Git) repository.
-   
-      -  *``ccrc://`` -* Fetches files from a ClearCase repository.
-   
-      -  *``http://`` -* Fetches files from the Internet using ``http``.
-   
-      -  *``https://`` -* Fetches files from the Internet using ``https``.
-   
-      -  *``ftp://`` -* Fetches files from the Internet using ``ftp``.
-   
-      -  *``cvs://`` -* Fetches files from a CVS revision control
+
+      -  ``repo://`` - Fetches files from a repo (Git) repository.
+
+      -  ``ccrc://`` - Fetches files from a ClearCase repository.
+
+      -  ``http://`` - Fetches files from the Internet using ``http``.
+
+      -  ``https://`` - Fetches files from the Internet using ``https``.
+
+      -  ``ftp://`` - Fetches files from the Internet using ``ftp``.
+
+      -  ``cvs://`` - Fetches files from a CVS revision control
          repository.
-   
-      -  *``hg://`` -* Fetches files from a Mercurial (``hg``) revision
+
+      -  ``hg://`` - Fetches files from a Mercurial (``hg``) revision
          control repository.
-   
-      -  *``p4://`` -* Fetches files from a Perforce (``p4``) revision
+
+      -  ``p4://`` - Fetches files from a Perforce (``p4``) revision
          control repository.
-   
-      -  *``ssh://`` -* Fetches files from a secure shell.
-   
-      -  *``svn://`` -* Fetches files from a Subversion (``svn``) revision
+
+      -  ``ssh://`` - Fetches files from a secure shell.
+
+      -  ``svn://`` - Fetches files from a Subversion (``svn``) revision
          control repository.
-   
-      -  *``npm://`` -* Fetches JavaScript modules from a registry.
-   
+
+      -  ``npm://`` - Fetches JavaScript modules from a registry.
+
       Standard and recipe-specific options for ``SRC_URI`` exist. Here are
       standard options:
-   
-      -  *``apply`` -* Whether to apply the patch or not. The default
+
+      -  ``apply`` - Whether to apply the patch or not. The default
          action is to apply the patch.
-   
-      -  *``striplevel`` -* Which striplevel to use when applying the
+
+      -  ``striplevel`` - Which striplevel to use when applying the
          patch. The default level is 1.
-   
-      -  *``patchdir`` -* Specifies the directory in which the patch should
+
+      -  ``patchdir`` - Specifies the directory in which the patch should
          be applied. The default is ``${``\ :term:`S`\ ``}``.
-   
+
       Here are options specific to recipes building code from a revision
       control system:
-   
-      -  *``mindate`` -* Apply the patch only if
+
+      -  ``mindate`` - Apply the patch only if
          :term:`SRCDATE` is equal to or greater than
          ``mindate``.
-   
-      -  *``maxdate`` -* Apply the patch only if ``SRCDATE`` is not later
+
+      -  ``maxdate`` - Apply the patch only if ``SRCDATE`` is not later
          than ``maxdate``.
-   
-      -  *``minrev`` -* Apply the patch only if ``SRCREV`` is equal to or
+
+      -  ``minrev`` - Apply the patch only if ``SRCREV`` is equal to or
          greater than ``minrev``.
-   
-      -  *``maxrev`` -* Apply the patch only if ``SRCREV`` is not later
+
+      -  ``maxrev`` - Apply the patch only if ``SRCREV`` is not later
          than ``maxrev``.
-   
-      -  *``rev`` -* Apply the patch only if ``SRCREV`` is equal to
+
+      -  ``rev`` - Apply the patch only if ``SRCREV`` is equal to
          ``rev``.
-   
-      -  *``notrev`` -* Apply the patch only if ``SRCREV`` is not equal to
+
+      -  ``notrev`` - Apply the patch only if ``SRCREV`` is not equal to
          ``rev``.
-   
+
       Here are some additional options worth mentioning:
-   
-      -  *``unpack`` -* Controls whether or not to unpack the file if it is
+
+      -  ``unpack`` - Controls whether or not to unpack the file if it is
          an archive. The default action is to unpack the file.
-   
-      -  *``destsuffix`` -* Places the file (or extracts its contents) into
+
+      -  ``destsuffix`` - Places the file (or extracts its contents) into
          the specified subdirectory of :term:`WORKDIR` when
          the Git fetcher is used.
-   
-      -  *``subdir`` -* Places the file (or extracts its contents) into the
+
+      -  ``subdir`` - Places the file (or extracts its contents) into the
          specified subdirectory of ``WORKDIR`` when the local (``file://``)
          fetcher is used.
-   
-      -  *``localdir`` -* Places the file (or extracts its contents) into
+
+      -  ``localdir`` - Places the file (or extracts its contents) into
          the specified subdirectory of ``WORKDIR`` when the CVS fetcher is
          used.
-   
-      -  *``subpath`` -* Limits the checkout to a specific subpath of the
+
+      -  ``subpath`` - Limits the checkout to a specific subpath of the
          tree when using the Git fetcher is used.
-   
-      -  *``name`` -* Specifies a name to be used for association with
+
+      -  ``name`` - Specifies a name to be used for association with
          ``SRC_URI`` checksums when you have more than one file specified
          in ``SRC_URI``.
-   
-      -  *``downloadfilename`` -* Specifies the filename used when storing
+
+      -  ``downloadfilename`` - Specifies the filename used when storing
          the downloaded file.
-   
+
    SRC_URI_OVERRIDES_PACKAGE_ARCH
       By default, the OpenEmbedded build system automatically detects
       whether ``SRC_URI`` contains files that are machine-specific. If so,
       the build system automatically changes ``PACKAGE_ARCH``. Setting this
       variable to "0" disables this behavior.
-   
+
    SRCDATE
       The date of the source code used to build the package. This variable
       applies only if the source was fetched from a Source Code Manager
       (SCM).
-   
+
    SRCPV
       Returns the version string of the current package. This string is
       used to help define the value of :term:`PV`.
-   
+
       The ``SRCPV`` variable is defined in the ``meta/conf/bitbake.conf``
       configuration file in the :term:`Source Directory` as
-      follows: SRCPV = "${@bb.fetch2.get_srcrev(d)}"
-   
+      follows:
+      ::
+
+         SRCPV = "${@bb.fetch2.get_srcrev(d)}"
+
       Recipes that need to define ``PV`` do so with the help of the
       ``SRCPV``. For example, the ``ofono`` recipe (``ofono_git.bb``)
       located in ``meta/recipes-connectivity`` in the Source Directory
-      defines ``PV`` as follows: PV = "0.12-git${SRCPV}"
-   
+      defines ``PV`` as follows:
+      ::
+
+         PV = "0.12-git${SRCPV}"
+
    SRCREV
       The revision of the source code used to build the package. This
       variable applies to Subversion, Git, Mercurial, and Bazaar only. Note
@@ -6412,9 +7220,9 @@ system and gives an overview of their function and contents.
       performing a query on the remote repository every time BitBake parses
       your recipe, you should specify a ``SRCREV`` that is a full revision
       identifier and not just a tag.
-   
+
       .. note::
-   
+
          For information on limitations when inheriting the latest revision
          of software using
          SRCREV
@@ -6423,10 +7231,10 @@ system and gives an overview of their function and contents.
          variable description and the "
          Automatically Incrementing a Binary Package Revision Number
          " section, which is in the Yocto Project Development Tasks Manual.
-   
+
    SSTATE_DIR
       The directory for the shared state cache.
-   
+
    SSTATE_MIRROR_ALLOW_NETWORK
       If set to "1", allows fetches from mirrors that are specified in
       :term:`SSTATE_MIRRORS` to work even when
@@ -6435,19 +7243,19 @@ system and gives an overview of their function and contents.
       you have set ``SSTATE_MIRRORS`` to point to an internal server for
       your shared state cache, but you want to disable any other fetching
       from the network.
-   
+
    SSTATE_MIRRORS
       Configures the OpenEmbedded build system to search other mirror
       locations for prebuilt cache data objects before building out the
       data. This variable works like fetcher :term:`MIRRORS`
       and :term:`PREMIRRORS` and points to the cache
       locations to check for the shared state (sstate) objects.
-   
+
       You can specify a filesystem directory or a remote URL such as HTTP
       or FTP. The locations you specify need to contain the shared state
       cache (sstate-cache) results from previous builds. The sstate-cache
       you point to can also be from builds on other machines.
-   
+
       When pointing to sstate build artifacts on another machine that uses
       a different GCC version for native builds, you must configure
       ``SSTATE_MIRRORS`` with a regular expression that maps local search
@@ -6455,24 +7263,27 @@ system and gives an overview of their function and contents.
       :term:`NATIVELSBSTRING` set by the
       :ref:`uninative <ref-classes-uninative>` class. For example, the
       following maps the local search path ``universal-4.9`` to the
-      server-provided path server_url_sstate_path: SSTATE_MIRRORS ?=
-      file://universal-4.9/(.*)
-      http://server_url_sstate_path/universal-4.8/\1 \\n
-   
+      server-provided path server_url_sstate_path:
+      ::
+
+         SSTATE_MIRRORS ?= "file://universal-4.9/(.*) http://server_url_sstate_path/universal-4.8/\1 \n"
+
       If a mirror uses the same structure as
       :term:`SSTATE_DIR`, you need to add "PATH" at the
       end as shown in the examples below. The build system substitutes the
-      correct path within the directory structure. SSTATE_MIRRORS ?= "\\
-      file://.\*
-      http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \\n \\
-      file://.\* file:///some-local-dir/sstate/PATH"
-   
+      correct path within the directory structure.
+      ::
+
+         SSTATE_MIRRORS ?= "\
+             file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
+             file://.* file:///some-local-dir/sstate/PATH"
+
    SSTATE_SCAN_FILES
       Controls the list of files the OpenEmbedded build system scans for
       hardcoded installation paths. The variable uses a space-separated
       list of filenames (not paths) with standard wildcard characters
       allowed.
-   
+
       During a build, the OpenEmbedded build system creates a shared state
       (sstate) object during the first stage of preparing the sysroots.
       That object is scanned for hardcoded paths for original installation
@@ -6482,32 +7293,32 @@ system and gives an overview of their function and contents.
       than the variable being comprehensively set. The
       :ref:`sstate <ref-classes-sstate>` class specifies the default list
       of files.
-   
+
       For details on the process, see the
       :ref:`staging <ref-classes-staging>` class.
-   
+
    STAGING_BASE_LIBDIR_NATIVE
       Specifies the path to the ``/lib`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAGING_BASELIBDIR
       Specifies the path to the ``/lib`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_BINDIR
       Specifies the path to the ``/usr/bin`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_BINDIR_CROSS
       Specifies the path to the directory containing binary configuration
       scripts. These scripts provide configuration information for other
       software that wants to make use of libraries or include files
       provided by the software associated with the script.
-   
+
       .. note::
-   
+
          This style of build configuration has been largely replaced by
          pkg-config
          . Consequently, if
@@ -6516,36 +7327,34 @@ system and gives an overview of their function and contents.
          recommended you use
          pkg-config
          instead of a provided configuration script.
-   
+
    STAGING_BINDIR_NATIVE
       Specifies the path to the ``/usr/bin`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAGING_DATADIR
       Specifies the path to the ``/usr/share`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_DATADIR_NATIVE
       Specifies the path to the ``/usr/share`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAGING_DIR
       Helps construct the ``recipe-sysroots`` directory, which is used
       during packaging.
-   
+
       For information on how staging for recipe-specific sysroots occurs,
       see the :ref:`ref-tasks-populate_sysroot`
-      task, the "`Sharing Files Between
-      Recipes <&YOCTO_DOCS_DEV_URL;#new-sharing-files-between-recipes>`__"
+      task, the ":ref:`sdk-manual/sdk-extensible:sharing files between recipes`"
       section in the Yocto Project Development Tasks Manual, the
-      "`Configuration, Compilation, and
-      Staging <&YOCTO_DOCS_OM_URL;#configuration-compilation-and-staging-dev-environment>`__"
+      ":ref:`configuration-compilation-and-staging-dev-environment`"
       section in the Yocto Project Overview and Concepts Manual, and the
       :term:`SYSROOT_DIRS` variable.
-   
+
       .. note::
-   
+
          Recipes should never write files directly under the
          STAGING_DIR
          directory because the OpenEmbedded build system manages the
@@ -6557,7 +7366,7 @@ system and gives an overview of their function and contents.
          do_install
          task and then the OpenEmbedded build system will stage a subset of
          those files into the sysroot.
-   
+
    STAGING_DIR_HOST
       Specifies the path to the sysroot directory for the system on which
       the component is built to run (the system that hosts the component).
@@ -6568,16 +7377,16 @@ system and gives an overview of their function and contents.
       :term:`STAGING_DIR_NATIVE`. Depending on
       the type of recipe and the build target, ``STAGING_DIR_HOST`` can
       have the following values:
-   
+
       -  For recipes building for the target machine, the value is
          "${:term:`STAGING_DIR`}/${:term:`MACHINE`}".
-   
+
       -  For native recipes building for the build host, the value is empty
          given the assumption that when building for the build host, the
          build host's own directories should be used.
-   
+
          .. note::
-   
+
             ``-native`` recipes are not installed into host paths like such
             as ``/usr``. Rather, these recipes are installed into
             ``STAGING_DIR_NATIVE``. When compiling ``-native`` recipes,
@@ -6586,7 +7395,7 @@ system and gives an overview of their function and contents.
             :term:`CFLAGS` are set up so that both host paths
             and ``STAGING_DIR_NATIVE`` are searched for libraries and
             headers using, for example, GCC's ``-isystem`` option.
-   
+
             Thus, the emphasis is that the ``STAGING_DIR*`` variables
             should be viewed as input variables by tasks such as
             :ref:`ref-tasks-configure`,
@@ -6595,17 +7404,17 @@ system and gives an overview of their function and contents.
             root correspond to ``STAGING_DIR_HOST`` makes conceptual sense
             for ``-native`` recipes, as they make use of host headers and
             libraries.
-   
+
    STAGING_DIR_NATIVE
       Specifies the path to the sysroot directory used when building
       components that run on the build host itself.
-   
+
    STAGING_DIR_TARGET
       Specifies the path to the sysroot used for the system for which the
       component generates code. For components that do not generate code,
       which is the majority, ``STAGING_DIR_TARGET`` is set to match
       :term:`STAGING_DIR_HOST`.
-   
+
       Some recipes build binaries that can run on the target system but
       those binaries in turn generate code for another different system
       (e.g. cross-canadian recipes). Using terminology from GNU, the
@@ -6615,171 +7424,203 @@ system and gives an overview of their function and contents.
       system. The ``STAGING_DIR_HOST`` variable points to the sysroot used
       for the "HOST" system, while ``STAGING_DIR_TARGET`` points to the
       sysroot used for the "TARGET" system.
-   
+
    STAGING_ETCDIR_NATIVE
       Specifies the path to the ``/etc`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAGING_EXECPREFIXDIR
       Specifies the path to the ``/usr`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_INCDIR
       Specifies the path to the ``/usr/include`` subdirectory of the
       sysroot directory for the target for which the current recipe being
       built (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_INCDIR_NATIVE
       Specifies the path to the ``/usr/include`` subdirectory of the
       sysroot directory for the build host.
-   
+
    STAGING_KERNEL_BUILDDIR
       Points to the directory containing the kernel build artifacts.
       Recipes building software that needs to access kernel build artifacts
       (e.g. ``systemtap-uprobes``) can look in the directory specified with
       the ``STAGING_KERNEL_BUILDDIR`` variable to find these artifacts
       after the kernel has been built.
-   
+
    STAGING_KERNEL_DIR
       The directory with kernel headers that are required to build
       out-of-tree modules.
-   
+
    STAGING_LIBDIR
       Specifies the path to the ``/usr/lib`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_LIBDIR_NATIVE
       Specifies the path to the ``/usr/lib`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAMP
       Specifies the base path used to create recipe stamp files. The path
       to an actual stamp file is constructed by evaluating this string and
       then appending additional information. Currently, the default
       assignment for ``STAMP`` as set in the ``meta/conf/bitbake.conf``
-      file is: STAMP =
-      "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
-   
+      file is:
+      ::
+
+         STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
+
       For information on how BitBake uses stamp files to determine if a
-      task should be rerun, see the "`Stamp Files and the Rerunning of
-      Tasks <&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks>`__"
+      task should be rerun, see the
+      ":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
       section in the Yocto Project Overview and Concepts Manual.
-   
+
       See :term:`STAMPS_DIR`,
       :term:`MULTIMACH_TARGET_SYS`,
       :term:`PN`, :term:`EXTENDPE`,
       :term:`PV`, and :term:`PR` for related variable
       information.
-   
+
    STAMPS_DIR
       Specifies the base directory in which the OpenEmbedded build system
       places stamps. The default directory is ``${TMPDIR}/stamps``.
-   
+
    STRIP
       The minimal command and arguments to run ``strip``, which is used to
       strip symbols.
-   
+
    SUMMARY
       The short (72 characters or less) summary of the binary package for
       packaging systems such as ``opkg``, ``rpm``, or ``dpkg``. By default,
       ``SUMMARY`` is used to define the
       :term:`DESCRIPTION` variable if ``DESCRIPTION`` is
       not set in the recipe.
-   
+
    SVNDIR
       The directory in which files checked out of a Subversion system are
       stored.
-   
+
    SYSLINUX_DEFAULT_CONSOLE
       Specifies the kernel boot default console. If you want to use a
       console other than the default, set this variable in your recipe as
       follows where "X" is the console number you want to use:
-      SYSLINUX_DEFAULT_CONSOLE = "console=ttyX"
-   
+      ::
+
+         SYSLINUX_DEFAULT_CONSOLE = "console=ttyX"
+
       The :ref:`syslinux <ref-classes-syslinux>` class initially sets
       this variable to null but then checks for a value later.
-   
+
    SYSLINUX_OPTS
       Lists additional options to add to the syslinux file. You need to set
       this variable in your recipe. If you want to list multiple options,
       separate the options with a semicolon character (``;``).
-   
+
       The :ref:`syslinux <ref-classes-syslinux>` class uses this variable
       to create a set of options.
-   
+
    SYSLINUX_SERIAL
       Specifies the alternate serial port or turns it off. To turn off
       serial, set this variable to an empty string in your recipe. The
       variable's default value is set in the
       :ref:`syslinux <ref-classes-syslinux>` class as follows:
-      SYSLINUX_SERIAL ?= "0 115200"
-   
+      ::
+
+         SYSLINUX_SERIAL ?= "0 115200"
+
       The class checks for and uses the variable as needed.
-   
+
    SYSLINUX_SPLASH
       An ``.LSS`` file used as the background for the VGA boot menu when
       you use the boot menu. You need to set this variable in your recipe.
-   
+
       The :ref:`syslinux <ref-classes-syslinux>` class checks for this
       variable and if found, the OpenEmbedded build system installs the
       splash screen.
-   
+
    SYSLINUX_SERIAL_TTY
       Specifies the alternate console=tty... kernel boot argument. The
       variable's default value is set in the
       :ref:`syslinux <ref-classes-syslinux>` class as follows:
-      SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200"
-   
+      ::
+
+         SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200"
+
       The class checks for and uses the variable as needed.
-   
+
    SYSROOT_DESTDIR
       Points to the temporary directory under the work directory (default
       "``${``\ :term:`WORKDIR`\ ``}/sysroot-destdir``")
       where the files populated into the sysroot are assembled during the
       :ref:`ref-tasks-populate_sysroot` task.
-   
+
    SYSROOT_DIRS
       Directories that are staged into the sysroot by the
       :ref:`ref-tasks-populate_sysroot` task. By
-      default, the following directories are staged: SYSROOT_DIRS = " \\
-      ${includedir} \\ ${libdir} \\ ${base_libdir} \\
-      ${nonarch_base_libdir} \\ ${datadir} \\ "
-   
+      default, the following directories are staged:
+      ::
+
+         SYSROOT_DIRS = " \
+             ${includedir} \
+             ${libdir} \
+             ${base_libdir} \
+             ${nonarch_base_libdir} \
+             ${datadir} \
+             "
+
    SYSROOT_DIRS_BLACKLIST
       Directories that are not staged into the sysroot by the
       :ref:`ref-tasks-populate_sysroot` task. You
       can use this variable to exclude certain subdirectories of
       directories listed in :term:`SYSROOT_DIRS` from
       staging. By default, the following directories are not staged:
-      SYSROOT_DIRS_BLACKLIST = " \\ ${mandir} \\ ${docdir} \\ ${infodir} \\
-      ${datadir}/locale \\ ${datadir}/applications \\ ${datadir}/fonts \\
-      ${datadir}/pixmaps \\ "
-   
+      ::
+
+         SYSROOT_DIRS_BLACKLIST = " \
+             ${mandir} \
+             ${docdir} \
+             ${infodir} \
+             ${datadir}/locale \
+             ${datadir}/applications \
+             ${datadir}/fonts \
+             ${datadir}/pixmaps \
+             "
+
    SYSROOT_DIRS_NATIVE
       Extra directories staged into the sysroot by the
       :ref:`ref-tasks-populate_sysroot` task for
       ``-native`` recipes, in addition to those specified in
       :term:`SYSROOT_DIRS`. By default, the following
-      extra directories are staged: SYSROOT_DIRS_NATIVE = " \\ ${bindir} \\
-      ${sbindir} \\ ${base_bindir} \\ ${base_sbindir} \\ ${libexecdir} \\
-      ${sysconfdir} \\ ${localstatedir} \\ "
-   
+      extra directories are staged:
+      ::
+
+         SYSROOT_DIRS_NATIVE = " \
+             ${bindir} \
+             ${sbindir} \
+             ${base_bindir} \
+             ${base_sbindir} \
+             ${libexecdir} \
+             ${sysconfdir} \
+             ${localstatedir} \
+             "
+
       .. note::
-   
+
          Programs built by
          -native
          recipes run directly from the sysroot (
          STAGING_DIR_NATIVE
          ), which is why additional directories containing program
          executables and supporting files need to be staged.
-   
+
    SYSROOT_PREPROCESS_FUNCS
       A list of functions to execute after files are staged into the
       sysroot. These functions are usually used to apply additional
       processing on the staged files, or to stage additional files.
-   
+
    SYSTEMD_AUTO_ENABLE
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
       this variable specifies whether the specified service in
@@ -6787,111 +7628,138 @@ system and gives an overview of their function and contents.
       automatically or not. By default, the service is enabled to
       automatically start at boot time. The default setting is in the
       :ref:`systemd <ref-classes-systemd>` class as follows:
-      SYSTEMD_AUTO_ENABLE ??= "enable"
-   
+      ::
+
+         SYSTEMD_AUTO_ENABLE ??= "enable"
+
       You can disable the service by setting the variable to "disable".
-   
+
    SYSTEMD_BOOT_CFG
       When :term:`EFI_PROVIDER` is set to
       "systemd-boot", the ``SYSTEMD_BOOT_CFG`` variable specifies the
       configuration file that should be used. By default, the
       :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
-      ``SYSTEMD_BOOT_CFG`` as follows: SYSTEMD_BOOT_CFG ?=
-      "${:term:`S`}/loader.conf"
-   
+      ``SYSTEMD_BOOT_CFG`` as follows:
+      ::
+
+         SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf"
+
       For information on Systemd-boot, see the `Systemd-boot
       documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
-   
+
    SYSTEMD_BOOT_ENTRIES
       When :term:`EFI_PROVIDER` is set to
       "systemd-boot", the ``SYSTEMD_BOOT_ENTRIES`` variable specifies a
       list of entry files (``*.conf``) to install that contain one boot
       entry per file. By default, the
       :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
-      ``SYSTEMD_BOOT_ENTRIES`` as follows: SYSTEMD_BOOT_ENTRIES ?= ""
-   
+      ``SYSTEMD_BOOT_ENTRIES`` as follows:
+      ::
+
+          SYSTEMD_BOOT_ENTRIES ?= ""
+
       For information on Systemd-boot, see the `Systemd-boot
       documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
-   
+
    SYSTEMD_BOOT_TIMEOUT
       When :term:`EFI_PROVIDER` is set to
       "systemd-boot", the ``SYSTEMD_BOOT_TIMEOUT`` variable specifies the
       boot menu timeout in seconds. By default, the
       :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
-      ``SYSTEMD_BOOT_TIMEOUT`` as follows: SYSTEMD_BOOT_TIMEOUT ?= "10"
-   
+      ``SYSTEMD_BOOT_TIMEOUT`` as follows:
+      ::
+
+         SYSTEMD_BOOT_TIMEOUT ?= "10"
+
       For information on Systemd-boot, see the `Systemd-boot
       documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
-   
+
    SYSTEMD_PACKAGES
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
       this variable locates the systemd unit files when they are not found
       in the main recipe's package. By default, the ``SYSTEMD_PACKAGES``
       variable is set such that the systemd unit files are assumed to
-      reside in the recipes main package: SYSTEMD_PACKAGES ?= "${PN}"
-   
+      reside in the recipes main package:
+      ::
+
+         SYSTEMD_PACKAGES ?= "${PN}"
+
       If these unit files are not in this recipe's main package, you need
       to use ``SYSTEMD_PACKAGES`` to list the package or packages in which
       the build system can find the systemd unit files.
-   
+
    SYSTEMD_SERVICE
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
       this variable specifies the systemd service name for a package.
-   
+
       When you specify this file in your recipe, use a package name
       override to indicate the package to which the value applies. Here is
-      an example from the connman recipe: SYSTEMD_SERVICE_${PN} =
-      "connman.service"
-   
+      an example from the connman recipe:
+      ::
+
+         SYSTEMD_SERVICE_${PN} = "connman.service"
+
    SYSVINIT_ENABLED_GETTYS
       When using
-      `SysVinit <&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services>`__,
+      :ref:`SysVinit <dev-manual/dev-manual-common-tasks:enabling system services>`,
       specifies a space-separated list of the virtual terminals that should
       run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__
       (allowing login), assuming :term:`USE_VT` is not set to
       "0".
-   
+
       The default value for ``SYSVINIT_ENABLED_GETTYS`` is "1" (i.e. only
       run a getty on the first virtual terminal).
-   
+
    T
       This variable points to a directory were BitBake places temporary
       files, which consist mostly of task logs and scripts, when building a
-      particular recipe. The variable is typically set as follows: T =
-      "${WORKDIR}/temp"
-   
+      particular recipe. The variable is typically set as follows:
+      ::
+
+         T = "${WORKDIR}/temp"
+
       The :term:`WORKDIR` is the directory into which
       BitBake unpacks and builds the recipe. The default ``bitbake.conf``
       file sets this variable.
-   
+
       The ``T`` variable is not to be confused with the
       :term:`TMPDIR` variable, which points to the root of
       the directory tree where BitBake places the output of an entire
       build.
-   
+
    TARGET_ARCH
       The target machine's architecture. The OpenEmbedded build system
       supports many architectures. Here is an example list of architectures
       supported. This list is by no means complete as the architecture is
-      configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel
-   
+      configurable:
+
+      - arm
+      - i586
+      - x86_64
+      - powerpc
+      - powerpc64
+      - mips
+      - mipsel
+
       For additional information on machine architectures, see the
       :term:`TUNE_ARCH` variable.
-   
+
    TARGET_AS_ARCH
       Specifies architecture-specific assembler flags for the target
       system. ``TARGET_AS_ARCH`` is initialized from
       :term:`TUNE_ASARGS` by default in the BitBake
-      configuration file (``meta/conf/bitbake.conf``): TARGET_AS_ARCH =
-      "${TUNE_ASARGS}"
-   
+      configuration file (``meta/conf/bitbake.conf``):
+      ::
+
+         TARGET_AS_ARCH = "${TUNE_ASARGS}"
+
    TARGET_CC_ARCH
       Specifies architecture-specific C compiler flags for the target
       system. ``TARGET_CC_ARCH`` is initialized from
       :term:`TUNE_CCARGS` by default.
-   
+
       .. note::
-   
+
          It is a common workaround to append
          LDFLAGS
          to
@@ -6900,7 +7768,7 @@ system and gives an overview of their function and contents.
          otherwise respect the exported
          LDFLAGS
          variable.
-   
+
    TARGET_CC_KERNEL_ARCH
       This is a specific kernel compiler flag for a CPU or Application
       Binary Interface (ABI) tune. The flag is used rarely and only for
@@ -6910,118 +7778,118 @@ system and gives an overview of their function and contents.
       different configuration. See the
       ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the
       :term:`Source Directory` for an example.
-   
+
    TARGET_CFLAGS
       Specifies the flags to pass to the C compiler when building for the
       target. When building in the target context,
       :term:`CFLAGS` is set to the value of this variable by
       default.
-   
+
       Additionally, the SDK's environment setup script sets the ``CFLAGS``
       variable in the environment to the ``TARGET_CFLAGS`` value so that
       executables built using the SDK also have the flags applied.
-   
+
    TARGET_CPPFLAGS
       Specifies the flags to pass to the C pre-processor (i.e. to both the
       C and the C++ compilers) when building for the target. When building
       in the target context, :term:`CPPFLAGS` is set to the
       value of this variable by default.
-   
+
       Additionally, the SDK's environment setup script sets the
       ``CPPFLAGS`` variable in the environment to the ``TARGET_CPPFLAGS``
       value so that executables built using the SDK also have the flags
       applied.
-   
+
    TARGET_CXXFLAGS
       Specifies the flags to pass to the C++ compiler when building for the
       target. When building in the target context,
       :term:`CXXFLAGS` is set to the value of this variable
       by default.
-   
+
       Additionally, the SDK's environment setup script sets the
       ``CXXFLAGS`` variable in the environment to the ``TARGET_CXXFLAGS``
       value so that executables built using the SDK also have the flags
       applied.
-   
+
    TARGET_FPU
       Specifies the method for handling FPU code. For FPU-less targets,
       which include most ARM CPUs, the variable must be set to "soft". If
       not, the kernel emulation gets used, which results in a performance
       penalty.
-   
+
    TARGET_LD_ARCH
       Specifies architecture-specific linker flags for the target system.
       ``TARGET_LD_ARCH`` is initialized from
       :term:`TUNE_LDARGS` by default in the BitBake
-      configuration file (``meta/conf/bitbake.conf``): TARGET_LD_ARCH =
-      "${TUNE_LDARGS}"
-   
+      configuration file (``meta/conf/bitbake.conf``):
+      ::
+
+         TARGET_LD_ARCH = "${TUNE_LDARGS}"
+
    TARGET_LDFLAGS
       Specifies the flags to pass to the linker when building for the
       target. When building in the target context,
       :term:`LDFLAGS` is set to the value of this variable
       by default.
-   
+
       Additionally, the SDK's environment setup script sets the
       :term:`LDFLAGS` variable in the environment to the
       ``TARGET_LDFLAGS`` value so that executables built using the SDK also
       have the flags applied.
-   
+
    TARGET_OS
       Specifies the target's operating system. The variable can be set to
       "linux" for glibc-based systems (GNU C Library) and to "linux-musl"
       for musl libc. For ARM/EABI targets, "linux-gnueabi" and
       "linux-musleabi" possible values exist.
-   
+
    TARGET_PREFIX
       Specifies the prefix used for the toolchain binary target tools.
-   
+
       Depending on the type of recipe and the build target,
       ``TARGET_PREFIX`` is set as follows:
-   
+
       -  For recipes building for the target machine, the value is
          "${:term:`TARGET_SYS`}-".
-   
+
       -  For native recipes, the build system sets the variable to the
          value of ``BUILD_PREFIX``.
-   
+
       -  For native SDK recipes (``nativesdk``), the build system sets the
          variable to the value of ``SDK_PREFIX``.
-   
+
    TARGET_SYS
       Specifies the system, including the architecture and the operating
       system, for which the build is occurring in the context of the
       current recipe.
-   
+
       The OpenEmbedded build system automatically sets this variable based
       on :term:`TARGET_ARCH`,
       :term:`TARGET_VENDOR`, and
       :term:`TARGET_OS` variables.
-   
+
       .. note::
-   
-         You do not need to set the
-         TARGET_SYS
-         variable yourself.
-   
+
+         You do not need to set the TARGET_SYS variable yourself.
+
       Consider these two examples:
-   
+
       -  Given a native recipe on a 32-bit, x86 machine running Linux, the
          value is "i686-linux".
-   
+
       -  Given a recipe being built for a little-endian, MIPS target
          running Linux, the value might be "mipsel-linux".
-   
+
    TARGET_VENDOR
       Specifies the name of the target vendor.
-   
+
    TCLIBC
       Specifies the GNU standard C library (``libc``) variant to use during
       the build process. This variable replaces ``POKYLIBC``, which is no
       longer supported.
-   
+
       You can select "glibc", "musl", "newlib", or "baremetal"
-   
+
    TCLIBCAPPEND
       Specifies a suffix to be appended onto the
       :term:`TMPDIR` value. The suffix identifies the
@@ -7029,13 +7897,13 @@ system and gives an overview of their function and contents.
       variants with the same :term:`Build Directory`, this
       mechanism ensures that output for different ``libc`` variants is kept
       separate to avoid potential conflicts.
-   
+
       In the ``defaultsetup.conf`` file, the default value of
       ``TCLIBCAPPEND`` is "-${TCLIBC}". However, distros such as poky,
       which normally only support one ``libc`` variant, set
       ``TCLIBCAPPEND`` to "" in their distro configuration file resulting
       in no suffix being applied.
-   
+
    TCMODE
       Specifies the toolchain selector. ``TCMODE`` controls the
       characteristics of the generated packages and images by telling the
@@ -7043,9 +7911,9 @@ system and gives an overview of their function and contents.
       the OpenEmbedded build system builds its own internal toolchain. The
       variable's default value is "default", which uses that internal
       toolchain.
-   
+
       .. note::
-   
+
          If
          TCMODE
          is set to a value other than "default", then it is your
@@ -7058,53 +7926,53 @@ system and gives an overview of their function and contents.
          Downloads
          page on the Yocto Project website and click on the "RELEASE
          INFORMATION" link for the appropriate release.
-   
+
       The ``TCMODE`` variable is similar to :term:`TCLIBC`,
       which controls the variant of the GNU standard C library (``libc``)
       used during the build process: ``glibc`` or ``musl``.
-   
+
       With additional layers, it is possible to use a pre-compiled external
       toolchain. One example is the Sourcery G++ Toolchain. The support for
       this toolchain resides in the separate Mentor Graphics
       ``meta-sourcery`` layer at
       http://github.com/MentorEmbedded/meta-sourcery/.
-   
+
       The layer's ``README`` file contains information on how to use the
       Sourcery G++ Toolchain as an external toolchain. In summary, you must
       be sure to add the layer to your ``bblayers.conf`` file in front of
       the ``meta`` layer and then set the ``EXTERNAL_TOOLCHAIN`` variable
       in your ``local.conf`` file to the location in which you installed
       the toolchain.
-   
+
       The fundamentals used for this example apply to any external
       toolchain. You can use ``meta-sourcery`` as a template for adding
       support for other external toolchains.
-   
+
    TEST_EXPORT_DIR
       The location the OpenEmbedded build system uses to export tests when
       the :term:`TEST_EXPORT_ONLY` variable is set
       to "1".
-   
+
       The ``TEST_EXPORT_DIR`` variable defaults to
       ``"${TMPDIR}/testimage/${PN}"``.
-   
+
    TEST_EXPORT_ONLY
       Specifies to export the tests only. Set this variable to "1" if you
       do not want to run the tests but you want them to be exported in a
       manner that you to run them outside of the build system.
-   
+
    TEST_LOG_DIR
       Holds the SSH log and the boot log for QEMU machines. The
       ``TEST_LOG_DIR`` variable defaults to ``"${WORKDIR}/testimage"``.
-   
+
       .. note::
-   
+
          Actual test results reside in the task log (
          log.do_testimage
          ), which is in the
          ${WORKDIR}/temp/
          directory.
-   
+
    TEST_POWERCONTROL_CMD
       For automated hardware testing, specifies the command to use to
       control the power of the target machine under test. Typically, this
@@ -7113,7 +7981,7 @@ system and gives an overview of their function and contents.
       command should expect to receive as the last argument "off", "on" or
       "cycle" specifying to power off, on, or cycle (power off and then
       power on) the device, respectively.
-   
+
    TEST_POWERCONTROL_EXTRA_ARGS
       For automated hardware testing, specifies additional arguments to
       pass through to the command specified in
@@ -7121,30 +7989,31 @@ system and gives an overview of their function and contents.
       ``TEST_POWERCONTROL_EXTRA_ARGS`` is optional. You can use it if you
       wish, for example, to separate the machine-specific and
       non-machine-specific parts of the arguments.
-   
+
    TEST_QEMUBOOT_TIMEOUT
       The time in seconds allowed for an image to boot before automated
       runtime tests begin to run against an image. The default timeout
       period to allow the boot process to reach the login prompt is 500
       seconds. You can specify a different value in the ``local.conf``
       file.
-   
-      For more information on testing images, see the "`Performing
-      Automated Runtime
-      Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+
+      For more information on testing images, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    TEST_SERIALCONTROL_CMD
       For automated hardware testing, specifies the command to use to
       connect to the serial console of the target machine under test. This
       command simply needs to connect to the serial console and forward
       that connection to standard input and output as any normal terminal
       program does.
-   
+
       For example, to use the Picocom terminal program on serial device
       ``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows:
-      TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
-   
+      ::
+
+         TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
+
    TEST_SERIALCONTROL_EXTRA_ARGS
       For automated hardware testing, specifies additional arguments to
       pass through to the command specified in
@@ -7152,238 +8021,273 @@ system and gives an overview of their function and contents.
       ``TEST_SERIALCONTROL_EXTRA_ARGS`` is optional. You can use it if you
       wish, for example, to separate the machine-specific and
       non-machine-specific parts of the command.
-   
+
    TEST_SERVER_IP
       The IP address of the build machine (host machine). This IP address
       is usually automatically detected. However, if detection fails, this
       variable needs to be set to the IP address of the build machine (i.e.
       where the build is taking place).
-   
+
       .. note::
-   
+
          The
          TEST_SERVER_IP
          variable is only used for a small number of tests such as the
          "dnf" test suite, which needs to download packages from
          WORKDIR/oe-rootfs-repo
          .
-   
+
    TEST_TARGET
       Specifies the target controller to use when running tests against a
-      test image. The default controller to use is "qemu": TEST_TARGET =
-      "qemu"
-   
+      test image. The default controller to use is "qemu":
+      ::
+
+         TEST_TARGET = "qemu"
+
       A target controller is a class that defines how an image gets
       deployed on a target and how a target is started. A layer can extend
       the controllers by adding a module in the layer's
       ``/lib/oeqa/controllers`` directory and by inheriting the
       ``BaseTarget`` class, which is an abstract class that cannot be used
       as a value of ``TEST_TARGET``.
-   
+
       You can provide the following arguments with ``TEST_TARGET``:
-   
+
       -  *"qemu":* Boots a QEMU image and runs the tests. See the
-         "`Enabling Runtime Tests on
-         QEMU <&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests>`__" section
+         ":ref:`qemu-image-enabling-tests`" section
          in the Yocto Project Development Tasks Manual for more
          information.
-   
+
       -  *"simpleremote":* Runs the tests on target hardware that is
          already up and running. The hardware can be on the network or it
          can be a device running an image on QEMU. You must also set
          :term:`TEST_TARGET_IP` when you use
          "simpleremote".
-   
+
          .. note::
-   
+
             This argument is defined in
             meta/lib/oeqa/controllers/simpleremote.py
             .
-   
-      For information on running tests on hardware, see the "`Enabling
-      Runtime Tests on
-      Hardware <&YOCTO_DOCS_DEV_URL;#hardware-image-enabling-tests>`__"
+
+      For information on running tests on hardware, see the
+      ":ref:`hardware-image-enabling-tests`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    TEST_TARGET_IP
       The IP address of your hardware under test. The ``TEST_TARGET_IP``
       variable has no effect when :term:`TEST_TARGET` is
       set to "qemu".
-   
+
       When you specify the IP address, you can also include a port. Here is
-      an example: TEST_TARGET_IP = "192.168.1.4:2201" Specifying a port is
+      an example:
+      ::
+
+         TEST_TARGET_IP = "192.168.1.4:2201"
+
+      Specifying a port is
       useful when SSH is started on a non-standard port or in cases when
       your hardware under test is behind a firewall or network that is not
       directly accessible from your host and you need to do port address
       translation.
-   
+
    TEST_SUITES
       An ordered list of tests (modules) to run against an image when
       performing automated runtime testing.
-   
+
       The OpenEmbedded build system provides a core set of tests that can
       be used against images.
-   
+
       .. note::
-   
+
          Currently, there is only support for running these tests under
          QEMU.
-   
+
       Tests include ``ping``, ``ssh``, ``df`` among others. You can add
       your own tests to the list of tests by appending ``TEST_SUITES`` as
-      follows: TEST_SUITES_append = " mytest" Alternatively, you can
+      follows:
+      ::
+
+         TEST_SUITES_append = " mytest"
+
+      Alternatively, you can
       provide the "auto" option to have all applicable tests run against
-      the image. TEST_SUITES_append = " auto" Using this option causes the
+      the image.
+      ::
+
+         TEST_SUITES_append = " auto"
+
+      Using this option causes the
       build system to automatically run tests that are applicable to the
       image. Tests that are not applicable are skipped.
-   
+
       The order in which tests are run is important. Tests that depend on
       another test must appear later in the list than the test on which
       they depend. For example, if you append the list of tests with two
       tests (``test_A`` and ``test_B``) where ``test_B`` is dependent on
-      ``test_A``, then you must order the tests as follows: TEST_SUITES = "
-      test_A test_B"
-   
-      For more information on testing images, see the "`Performing
-      Automated Runtime
-      Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+      ``test_A``, then you must order the tests as follows:
+      ::
+
+         TEST_SUITES = "test_A test_B"
+
+      For more information on testing images, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    TESTIMAGE_AUTO
       Automatically runs the series of automated tests for images when an
       image is successfully built. Setting ``TESTIMAGE_AUTO`` to "1" causes
       any image that successfully builds to automatically boot under QEMU.
       Using the variable also adds in dependencies so that any SDK for
       which testing is requested is automatically built first.
-   
+
       These tests are written in Python making use of the ``unittest``
       module, and the majority of them run commands on the target system
       over ``ssh``. You can set this variable to "1" in your ``local.conf``
       file in the :term:`Build Directory` to have the
       OpenEmbedded build system automatically run these tests after an
-      image successfully builds: TESTIMAGE_AUTO = "1" For more information
-      on enabling, running, and writing these tests, see the "`Performing
-      Automated Runtime
-      Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+      image successfully builds:
+
+         TESTIMAGE_AUTO = "1"
+
+      For more information
+      on enabling, running, and writing these tests, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual and the
       ":ref:`testimage*.bbclass <ref-classes-testimage*>`" section.
-   
+
    THISDIR
       The directory in which the file BitBake is currently parsing is
       located. Do not manually set this variable.
-   
+
    TIME
       The time the build was started. Times appear using the hour, minute,
       and second (HMS) format (e.g. "140159" for one minute and fifty-nine
       seconds past 1400 hours).
-   
+
    TMPDIR
       This variable is the base directory the OpenEmbedded build system
       uses for all build output and intermediate files (other than the
       shared state cache). By default, the ``TMPDIR`` variable points to
       ``tmp`` within the :term:`Build Directory`.
-   
+
       If you want to establish this directory in a location other than the
       default, you can uncomment and edit the following statement in the
       ``conf/local.conf`` file in the :term:`Source Directory`:
-      #TMPDIR = "${TOPDIR}/tmp" An
-      example use for this scenario is to set ``TMPDIR`` to a local disk,
+      ::
+
+         #TMPDIR = "${TOPDIR}/tmp"
+
+      An example use for this scenario is to set ``TMPDIR`` to a local disk,
       which does not use NFS, while having the Build Directory use NFS.
-   
+
       The filesystem used by ``TMPDIR`` must have standard filesystem
       semantics (i.e. mixed-case files are unique, POSIX file locking, and
       persistent inodes). Due to various issues with NFS and bugs in some
       implementations, NFS does not meet this minimum requirement.
       Consequently, ``TMPDIR`` cannot be on NFS.
-   
+
    TOOLCHAIN_HOST_TASK
       This variable lists packages the OpenEmbedded build system uses when
       building an SDK, which contains a cross-development environment. The
       packages specified by this variable are part of the toolchain set
       that runs on the :term:`SDKMACHINE`, and each
       package should usually have the prefix ``nativesdk-``. For example,
-      consider the following command when building an SDK: $ bitbake -c
-      populate_sdk imagename In this case, a default list of packages is
+      consider the following command when building an SDK:
+      ::
+
+         $ bitbake -c populate_sdk imagename
+
+      In this case, a default list of packages is
       set in this variable, but you can add additional packages to the
-      list. See the "`Adding Individual Packages to the Standard
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-adding-individual-packages>`__" section
+      list. See the
+      ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
       in the Yocto Project Application Development and the Extensible
       Software Development Kit (eSDK) manual for more information.
-   
+
       For background information on cross-development toolchains in the
-      Yocto Project development environment, see the "`Cross-Development
-      Toolchain
-      Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__"
+      Yocto Project development environment, see the
+      ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
       section in the Yocto Project Overview and Concepts Manual. For
       information on setting up a cross-development environment, see the
-      `Yocto Project Application Development and the Extensible Software
-      Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual.
-   
+      :doc:`../sdk-manual/sdk-manual` manual.
+
    TOOLCHAIN_OUTPUTNAME
       This variable defines the name used for the toolchain output. The
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets
       the ``TOOLCHAIN_OUTPUTNAME`` variable as follows:
-      TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See
+      ::
+
+         TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
+
+      See
       the :term:`SDK_NAME` and
       :term:`SDK_VERSION` variables for additional
       information.
-   
+
    TOOLCHAIN_TARGET_TASK
       This variable lists packages the OpenEmbedded build system uses when
       it creates the target part of an SDK (i.e. the part built for the
       target hardware), which includes libraries and headers. Use this
       variable to add individual packages to the part of the SDK that runs
-      on the target. See the "`Adding Individual Packages to the Standard
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-adding-individual-packages>`__" section
+      on the target. See the
+      ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
       in the Yocto Project Application Development and the Extensible
       Software Development Kit (eSDK) manual for more information.
-   
+
       For background information on cross-development toolchains in the
-      Yocto Project development environment, see the "`Cross-Development
-      Toolchain
-      Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__"
+      Yocto Project development environment, see the
+      ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
       section in the Yocto Project Overview and Concepts Manual. For
       information on setting up a cross-development environment, see the
-      `Yocto Project Application Development and the Extensible Software
-      Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual.
-   
+      :doc:`../sdk-manual/sdk-manual` manual.
+
    TOPDIR
       The top-level :term:`Build Directory`. BitBake
       automatically sets this variable when you initialize your build
       environment using ````` <#structure-core-script>`__.
-   
+
    TRANSLATED_TARGET_ARCH
       A sanitized version of :term:`TARGET_ARCH`. This
       variable is used where the architecture is needed in a value where
       underscores are not allowed, for example within package filenames. In
       this case, dash characters replace any underscore characters used in
       ``TARGET_ARCH``.
-   
+
       Do not edit this variable.
-   
+
    TUNE_ARCH
       The GNU canonical architecture for a specific architecture (i.e.
       ``arm``, ``armeb``, ``mips``, ``mips64``, and so forth). BitBake uses
       this value to setup configuration.
-   
+
       ``TUNE_ARCH`` definitions are specific to a given architecture. The
       definitions can be a single static definition, or can be dynamically
       adjusted. You can see details for a given CPU family by looking at
       the architecture's ``README`` file. For example, the
-      ``meta/conf/machine/include/mips/README`` file in the 
+      ``meta/conf/machine/include/mips/README`` file in the
       :term:`Source Directory` provides information for
       ``TUNE_ARCH`` specific to the ``mips`` architecture.
-   
+
       ``TUNE_ARCH`` is tied closely to
       :term:`TARGET_ARCH`, which defines the target
       machine's architecture. The BitBake configuration file
       (``meta/conf/bitbake.conf``) sets ``TARGET_ARCH`` as follows:
-      TARGET_ARCH = "${TUNE_ARCH}"
-   
+      ::
+
+         TARGET_ARCH = "${TUNE_ARCH}"
+
       The following list, which is by no means complete since architectures
-      are configurable, shows supported machine architectures: arm i586
-      x86_64 powerpc powerpc64 mips mipsel
-   
+      are configurable, shows supported machine architectures:
+
+      - arm
+      - i586
+      - x86_64
+      - powerpc
+      - powerpc64
+      - mips
+      - mipsel
+
    TUNE_ASARGS
       Specifies architecture-specific assembler flags for the target
       system. The set of flags is based on the selected tune features.
@@ -7391,28 +8295,30 @@ system and gives an overview of their function and contents.
       typically under ``meta/conf/machine/include/`` and are influenced
       through :term:`TUNE_FEATURES`. For example, the
       ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
-      for the x86 architecture as follows: TUNE_ASARGS +=
-      "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
-   
+      for the x86 architecture as follows:
+      ::
+
+         TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
+
       .. note::
-   
+
          Board Support Packages (BSPs) select the tune. The selected tune,
          in turn, affects the tune variables themselves (i.e. the tune can
          supply its own set of flags).
-   
+
    TUNE_CCARGS
       Specifies architecture-specific C compiler flags for the target
       system. The set of flags is based on the selected tune features.
       ``TUNE_CCARGS`` is set using the tune include files, which are
       typically under ``meta/conf/machine/include/`` and are influenced
       through :term:`TUNE_FEATURES`.
-   
+
       .. note::
-   
+
          Board Support Packages (BSPs) select the tune. The selected tune,
          in turn, affects the tune variables themselves (i.e. the tune can
          supply its own set of flags).
-   
+
    TUNE_LDARGS
       Specifies architecture-specific linker flags for the target system.
       The set of flags is based on the selected tune features.
@@ -7420,41 +8326,49 @@ system and gives an overview of their function and contents.
       typically under ``meta/conf/machine/include/`` and are influenced
       through :term:`TUNE_FEATURES`. For example, the
       ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
-      for the x86 architecture as follows: TUNE_LDARGS +=
-      "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "",
-      d)}"
-   
+      for the x86 architecture as follows:
+      ::
+
+         TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}"
+
       .. note::
-   
+
          Board Support Packages (BSPs) select the tune. The selected tune,
          in turn, affects the tune variables themselves (i.e. the tune can
          supply its own set of flags).
-   
+
    TUNE_FEATURES
       Features used to "tune" a compiler for optimal use given a specific
       processor. The features are defined within the tune files and allow
       arguments (i.e. ``TUNE_*ARGS``) to be dynamically generated based on
       the features.
-   
+
       The OpenEmbedded build system verifies the features to be sure they
       are not conflicting and that they are supported.
-   
+
       The BitBake configuration file (``meta/conf/bitbake.conf``) defines
-      ``TUNE_FEATURES`` as follows: TUNE_FEATURES ??=
-      "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" See the
-      :term:`DEFAULTTUNE` variable for more information.
-   
+      ``TUNE_FEATURES`` as follows:
+      ::
+
+         TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
+
+      See the :term:`DEFAULTTUNE` variable for more information.
+
    TUNE_PKGARCH
       The package architecture understood by the packaging system to define
       the architecture, ABI, and tuning of output packages. The specific
       tune is defined using the "_tune" override as follows:
-      TUNE_PKGARCH_tune-tune = "tune"
-   
+      ::
+
+         TUNE_PKGARCH_tune-tune = "tune"
+
       These tune-specific package architectures are defined in the machine
       include files. Here is an example of the "core2-32" tuning as used in
       the ``meta/conf/machine/include/tune-core2.inc`` file:
-      TUNE_PKGARCH_tune-core2-32 = "core2-32"
-   
+      ::
+
+         TUNE_PKGARCH_tune-core2-32 = "core2-32"
+
    TUNEABI
       An underlying Application Binary Interface (ABI) used by a particular
       tuning in a given toolchain layer. Providers that use prebuilt
@@ -7462,11 +8376,11 @@ system and gives an overview of their function and contents.
       :term:`TUNEABI_OVERRIDE`, and
       :term:`TUNEABI_WHITELIST` variables to check
       compatibility of tunings against their selection of libraries.
-   
+
       If ``TUNEABI`` is undefined, then every tuning is allowed. See the
       :ref:`sanity <ref-classes-sanity>` class to see how the variable is
       used.
-   
+
    TUNEABI_OVERRIDE
       If set, the OpenEmbedded system ignores the
       :term:`TUNEABI_WHITELIST` variable.
@@ -7474,10 +8388,10 @@ system and gives an overview of their function and contents.
       ``TUNEABI_OVERRIDE``, ``TUNEABI_WHITELIST``, and
       :term:`TUNEABI` variables to check compatibility of a
       tuning against their selection of libraries.
-   
+
       See the :ref:`sanity <ref-classes-sanity>` class to see how the
       variable is used.
-   
+
    TUNEABI_WHITELIST
       A whitelist of permissible :term:`TUNEABI` values. If
       ``TUNEABI_WHITELIST`` is not set, all tunes are allowed. Providers
@@ -7485,100 +8399,112 @@ system and gives an overview of their function and contents.
       :term:`TUNEABI_OVERRIDE`, and ``TUNEABI``
       variables to check compatibility of a tuning against their selection
       of libraries.
-   
+
       See the :ref:`sanity <ref-classes-sanity>` class to see how the
       variable is used.
-   
+
    TUNECONFLICTS[feature]
       Specifies CPU or Application Binary Interface (ABI) tuning features
       that conflict with feature.
-   
+
       Known tuning conflicts are specified in the machine include files in
       the :term:`Source Directory`. Here is an example from
       the ``meta/conf/machine/include/mips/arch-mips.inc`` include file
       that lists the "o32" and "n64" features as conflicting with the "n32"
-      feature: TUNECONFLICTS[n32] = "o32 n64"
-   
+      feature:
+      ::
+
+         TUNECONFLICTS[n32] = "o32 n64"
+
    TUNEVALID[feature]
       Specifies a valid CPU or Application Binary Interface (ABI) tuning
       feature. The specified feature is stored as a flag. Valid features
       are specified in the machine include files (e.g.
       ``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example
-      from that file: TUNEVALID[bigendian] = "Enable big-endian mode."
-   
+      from that file:
+      ::
+
+         TUNEVALID[bigendian] = "Enable big-endian mode."
+
       See the machine include files in the :term:`Source Directory`
       for these features.
-   
+
    UBOOT_CONFIG
       Configures the :term:`UBOOT_MACHINE` and can
       also define :term:`IMAGE_FSTYPES` for individual
       cases.
-   
-      Following is an example from the ``meta-fsl-arm`` layer. UBOOT_CONFIG
-      ??= "sd" UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
-      UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
-      UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
-      UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config" In this example,
-      "sd" is selected as the configuration of the possible four for the
+
+      Following is an example from the ``meta-fsl-arm`` layer. ::
+
+         UBOOT_CONFIG ??= "sd"
+         UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
+         UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
+         UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
+         UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"
+
+      In this example, "sd" is selected as the configuration of the possible four for the
       ``UBOOT_MACHINE``. The "sd" configuration defines
       "mx6qsabreauto_config" as the value for ``UBOOT_MACHINE``, while the
       "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-boot image.
-   
+
       For more information on how the ``UBOOT_CONFIG`` is handled, see the
-      ```uboot-config`http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-config.bbclass
+      :ref:`uboot-config <ref-classes-uboot-config>`
       class.
 
    UBOOT_DTB_LOADADDRESS
       Specifies the load address for the dtb image used by U-boot. During FIT
       image creation, the ``UBOOT_DTB_LOADADDRESS`` variable is used in
-      ``kernel-fitimage`` class to specify the load address to be used in
+      :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify
+      the load address to be used in
       creating the dtb sections of Image Tree Source for the FIT image.
 
    UBOOT_DTBO_LOADADDRESS
       Specifies the load address for the dtbo image used by U-boot.  During FIT
       image creation, the ``UBOOT_DTBO_LOADADDRESS`` variable is used in
-      ``kernel-fitimage`` class to specify the load address to be used in
+      :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the load address to be used in
       creating the dtbo sections of Image Tree Source for the FIT image.
-   
+
    UBOOT_ENTRYPOINT
       Specifies the entry point for the U-Boot image. During U-Boot image
       creation, the ``UBOOT_ENTRYPOINT`` variable is passed as a
       command-line parameter to the ``uboot-mkimage`` utility.
-   
+
    UBOOT_LOADADDRESS
       Specifies the load address for the U-Boot image. During U-Boot image
       creation, the ``UBOOT_LOADADDRESS`` variable is passed as a
       command-line parameter to the ``uboot-mkimage`` utility.
-   
+
    UBOOT_LOCALVERSION
       Appends a string to the name of the local version of the U-Boot
       image. For example, assuming the version of the U-Boot image built
       was "2013.10", the full version string reported by U-Boot would be
-      "2013.10-yocto" given the following statement: UBOOT_LOCALVERSION =
-      "-yocto"
-   
+      "2013.10-yocto" given the following statement:
+      ::
+
+         UBOOT_LOCALVERSION = "-yocto"
+
    UBOOT_MACHINE
       Specifies the value passed on the ``make`` command line when building
       a U-Boot image. The value indicates the target platform
       configuration. You typically set this variable from the machine
       configuration file (i.e. ``conf/machine/machine_name.conf``).
-   
+
       Please see the "Selection of Processor Architecture and Board Type"
       section in the U-Boot README for valid values for this variable.
-   
+
    UBOOT_MAKE_TARGET
       Specifies the target called in the ``Makefile``. The default target
       is "all".
 
    UBOOT_MKIMAGE_DTCOPTS
       Options for the device tree compiler passed to mkimage '-D'
-      feature while creating FIT image in ``kernel-fitimage`` class.
+      feature while creating FIT image in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class.
 
    UBOOT_RD_LOADADDRESS
       Specifies the load address for the RAM disk image.
       During FIT image creation, the
       ``UBOOT_RD_LOADADDRESS`` variable is used
-      in ``kernel-fitimage`` class to specify the
+      in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the
       load address to be used in creating the Image Tree Source for
       the FIT image.
 
@@ -7586,10 +8512,10 @@ system and gives an overview of their function and contents.
       Specifies the entrypoint for the RAM disk image.
       During FIT image creation, the
       ``UBOOT_RD_ENTRYPOINT`` variable is used
-      in ``kernel-fitimage`` class to specify the
+      in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the
       entrypoint to be used in creating the Image Tree Source for
       the FIT image.
-   
+
    UBOOT_SIGN_ENABLE
       Enable signing of FIT image. The default value is "0".
 
@@ -7628,40 +8554,44 @@ system and gives an overview of their function and contents.
       configure scripts. It follows that no benefit exists in seeing a
       warning about these options. For these cases, the options are added
       to ``UNKNOWN_CONFIGURE_WHITELIST``.
-   
+
       The configure arguments check that uses
       ``UNKNOWN_CONFIGURE_WHITELIST`` is part of the
       :ref:`insane <ref-classes-insane>` class and is only enabled if the
       recipe inherits the :ref:`autotools <ref-classes-autotools>` class.
-   
+
    UPDATERCPN
       For recipes inheriting the
       :ref:`update-rc.d <ref-classes-update-rc.d>` class, ``UPDATERCPN``
       specifies the package that contains the initscript that is enabled.
-   
+
       The default value is "${PN}". Given that almost all recipes that
       install initscripts package them in the main package for the recipe,
       you rarely need to set this variable in individual recipes.
-   
+
    UPSTREAM_CHECK_GITTAGREGEX
       You can perform a per-recipe check for what the latest upstream
       source code version is by calling ``bitbake -c checkpkg`` recipe. If
       the recipe source code is provided from Git repositories, the
       OpenEmbedded build system determines the latest upstream version by
       picking the latest tag from the list of all repository tags.
-   
+
       You can use the ``UPSTREAM_CHECK_GITTAGREGEX`` variable to provide a
       regular expression to filter only the relevant tags should the
-      default filter not work correctly. UPSTREAM_CHECK_GITTAGREGEX =
-      "git_tag_regex"
-   
+      default filter not work correctly.
+      ::
+
+         UPSTREAM_CHECK_GITTAGREGEX = "git_tag_regex"
+
    UPSTREAM_CHECK_REGEX
       Use the ``UPSTREAM_CHECK_REGEX`` variable to specify a different
       regular expression instead of the default one when the package
       checking system is parsing the page found using
       :term:`UPSTREAM_CHECK_URI`.
-      UPSTREAM_CHECK_REGEX = "package_regex"
-   
+      ::
+
+         UPSTREAM_CHECK_REGEX = "package_regex"
+
    UPSTREAM_CHECK_URI
       You can perform a per-recipe check for what the latest upstream
       source code version is by calling ``bitbake -c checkpkg`` recipe. If
@@ -7669,43 +8599,48 @@ system and gives an overview of their function and contents.
       determined by fetching the directory listing where the tarball is and
       attempting to find a later tarball. When this approach does not work,
       you can use ``UPSTREAM_CHECK_URI`` to provide a different URI that
-      contains the link to the latest tarball. UPSTREAM_CHECK_URI =
-      "recipe_url"
-   
+      contains the link to the latest tarball.
+      ::
+
+         UPSTREAM_CHECK_URI = "recipe_url"
+
    USE_DEVFS
       Determines if ``devtmpfs`` is used for ``/dev`` population. The
       default value used for ``USE_DEVFS`` is "1" when no value is
       specifically set. Typically, you would set ``USE_DEVFS`` to "0" for a
       statically populated ``/dev`` directory.
-   
-      See the "`Selecting a Device
-      Manager <&YOCTO_DOCS_DEV_URL;#selecting-dev-manager>`__" section in
+
+      See the ":ref:`selecting-dev-manager`" section in
       the Yocto Project Development Tasks Manual for information on how to
       use this variable.
-   
+
    USE_VT
       When using
-      `SysVinit <&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services>`__,
+      :ref:`SysVinit <new-recipe-enabling-system-services>`,
       determines whether or not to run a
       `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any
       virtual terminals in order to enable logging in through those
       terminals.
-   
+
       The default value used for ``USE_VT`` is "1" when no default value is
       specifically set. Typically, you would set ``USE_VT`` to "0" in the
       machine configuration file for machines that do not have a graphical
       display attached and therefore do not need virtual terminal
       functionality.
-   
+
    USER_CLASSES
       A list of classes to globally inherit. These classes are used by the
       OpenEmbedded build system to enable extra features (e.g.
       ``buildstats``, ``image-mklibs``, and so forth).
-   
-      The default list is set in your ``local.conf`` file: USER_CLASSES ?=
-      "buildstats image-mklibs image-prelink" For more information, see
+
+      The default list is set in your ``local.conf`` file:
+      ::
+
+         USER_CLASSES ?= "buildstats image-mklibs image-prelink"
+
+      For more information, see
       ``meta-poky/conf/local.conf.sample`` in the :term:`Source Directory`.
-   
+
    USERADD_ERROR_DYNAMIC
       If set to ``error``, forces the OpenEmbedded build system to produce
       an error if the user identification (``uid``) and group
@@ -7713,21 +8648,26 @@ system and gives an overview of their function and contents.
       listed in :term:`USERADD_UID_TABLES` and
       :term:`USERADD_GID_TABLES`. If set to
       ``warn``, a warning will be issued instead.
-   
+
       The default behavior for the build system is to dynamically apply
       ``uid`` and ``gid`` values. Consequently, the
       ``USERADD_ERROR_DYNAMIC`` variable is by default not set. If you plan
       on using statically assigned ``gid`` and ``uid`` values, you should
       set the ``USERADD_ERROR_DYNAMIC`` variable in your ``local.conf``
-      file as follows: USERADD_ERROR_DYNAMIC = "error" Overriding the
+      file as follows:
+      ::
+
+         USERADD_ERROR_DYNAMIC = "error"
+
+      Overriding the
       default behavior implies you are going to also take steps to set
       static ``uid`` and ``gid`` values through use of the
       :term:`USERADDEXTENSION`,
       :term:`USERADD_UID_TABLES`, and
       :term:`USERADD_GID_TABLES` variables.
-   
+
       .. note::
-   
+
          There is a difference in behavior between setting
          USERADD_ERROR_DYNAMIC
          to
@@ -7745,38 +8685,44 @@ system and gives an overview of their function and contents.
          , it will only report errors for recipes that are actually built.
          This saves you from having to add static IDs for recipes that you
          know will never be built.
-   
+
    USERADD_GID_TABLES
       Specifies a password file to use for obtaining static group
       identification (``gid``) values when the OpenEmbedded build system
       adds a group to the system during package installation.
-   
+
       When applying static group identification (``gid``) values, the
       OpenEmbedded build system looks in :term:`BBPATH` for a
       ``files/group`` file and then applies those ``uid`` values. Set the
-      variable as follows in your ``local.conf`` file: USERADD_GID_TABLES =
-      "files/group"
-   
+      variable as follows in your ``local.conf`` file:
+      ::
+
+
+         USERADD_GID_TABLES = "files/group"
+
       .. note::
-   
+
          Setting the
          USERADDEXTENSION
          variable to "useradd-staticids" causes the build system to use
          static
          gid
          values.
-   
+
    USERADD_PACKAGES
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
       this variable specifies the individual packages within the recipe
       that require users and/or groups to be added.
-   
+
       You must set this variable if the recipe inherits the class. For
       example, the following enables adding a user for the main package in
-      a recipe: USERADD_PACKAGES = "${PN}"
-   
+      a recipe:
+      ::
+
+         USERADD_PACKAGES = "${PN}"
+
       .. note::
-   
+
          It follows that if you are going to use the
          USERADD_PACKAGES
          variable, you need to set one or more of the
@@ -7786,50 +8732,57 @@ system and gives an overview of their function and contents.
          , or
          GROUPMEMS_PARAM
          variables.
-   
+
    USERADD_PARAM
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
       this variable specifies for a package what parameters should pass to
       the ``useradd`` command if you add a user to the system when the
       package is installed.
-   
-      Here is an example from the ``dbus`` recipe: USERADD_PARAM_${PN} =
-      "--system --home ${localstatedir}/lib/dbus \\ --no-create-home
-      --shell /bin/false \\ --user-group messagebus" For information on the
+
+      Here is an example from the ``dbus`` recipe:
+      ::
+
+         USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
+                                --no-create-home --shell /bin/false \
+                                --user-group messagebus"
+
+      For information on the
       standard Linux shell command ``useradd``, see
       http://linux.die.net/man/8/useradd.
-   
+
    USERADD_UID_TABLES
       Specifies a password file to use for obtaining static user
       identification (``uid``) values when the OpenEmbedded build system
       adds a user to the system during package installation.
-   
+
       When applying static user identification (``uid``) values, the
       OpenEmbedded build system looks in :term:`BBPATH` for a
       ``files/passwd`` file and then applies those ``uid`` values. Set the
-      variable as follows in your ``local.conf`` file: USERADD_UID_TABLES =
-      "files/passwd"
-   
+      variable as follows in your ``local.conf`` file:
+      ::
+
+         USERADD_UID_TABLES = "files/passwd"
+
       .. note::
-   
+
          Setting the
          USERADDEXTENSION
          variable to "useradd-staticids" causes the build system to use
          static
          uid
          values.
-   
+
    USERADDEXTENSION
       When set to "useradd-staticids", causes the OpenEmbedded build system
       to base all user and group additions on a static ``passwd`` and
       ``group`` files found in :term:`BBPATH`.
-   
+
       To use static user identification (``uid``) and group identification
       (``gid``) values, set the variable as follows in your ``local.conf``
       file: USERADDEXTENSION = "useradd-staticids"
-   
+
       .. note::
-   
+
          Setting this variable to use static
          uid
          and
@@ -7837,29 +8790,29 @@ system and gives an overview of their function and contents.
          values causes the OpenEmbedded build system to employ the
          useradd-staticids
          class.
-   
+
       If you use static ``uid`` and ``gid`` information, you must also
       specify the ``files/passwd`` and ``files/group`` files by setting the
       :term:`USERADD_UID_TABLES` and
       :term:`USERADD_GID_TABLES` variables.
       Additionally, you should also set the
       :term:`USERADD_ERROR_DYNAMIC` variable.
-   
+
    VOLATILE_LOG_DIR
       Specifies the persistence of the target's ``/var/log`` directory,
       which is used to house postinstall target log files.
-   
+
       By default, ``VOLATILE_LOG_DIR`` is set to "yes", which means the
       file is not persistent. You can override this setting by setting the
       variable to "no" to make the log directory persistent.
-   
+
    WARN_QA
       Specifies the quality assurance checks whose failures are reported as
       warnings by the OpenEmbedded build system. You set this variable in
       your distribution configuration file. For a list of the checks you
       can control with this variable, see the
       ":ref:`insane.bbclass <ref-classes-insane>`" section.
-   
+
    WKS_FILE_DEPENDS
       When placed in the recipe that builds your image, this variable lists
       build-time dependencies. The ``WKS_FILE_DEPENDS`` variable is only
@@ -7867,39 +8820,46 @@ system and gives an overview of their function and contents.
       :term:`IMAGE_FSTYPES` contains entries related
       to Wic). If your recipe does not create Wic images, the variable has
       no effect.
-   
+
       The ``WKS_FILE_DEPENDS`` variable is similar to the
       :term:`DEPENDS` variable. When you use the variable in
       your recipe that builds the Wic image, dependencies you list in the
       ``WIC_FILE_DEPENDS`` variable are added to the ``DEPENDS`` variable.
-   
+
       With the ``WKS_FILE_DEPENDS`` variable, you have the possibility to
       specify a list of additional dependencies (e.g. native tools,
       bootloaders, and so forth), that are required to build Wic images.
-      Following is an example: WKS_FILE_DEPENDS = "some-native-tool" In the
+      Following is an example:
+      ::
+
+         WKS_FILE_DEPENDS = "some-native-tool"
+
+      In the
       previous example, some-native-tool would be replaced with an actual
       native tool on which the build would depend.
-   
+
    WKS_FILE
       Specifies the location of the Wic kickstart file that is used by the
       OpenEmbedded build system to create a partitioned image
       (image\ ``.wic``). For information on how to create a partitioned
-      image, see the "`Creating Partitioned Images Using
-      Wic <&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic>`__"
+      image, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
       section in the Yocto Project Development Tasks Manual. For details on
-      the kickstart file format, see the "`OpenEmbedded Kickstart
-      (``.wks``) Reference <#ref-kickstart>`__" Chapter.
-   
+      the kickstart file format, see the ":doc:`../ref-manual/ref-kickstart`" Chapter.
+
    WORKDIR
       The pathname of the work directory in which the OpenEmbedded build
       system builds a recipe. This directory is located within the
       :term:`TMPDIR` directory structure and is specific to
       the recipe being built and the system for which it is being built.
-   
+
       The ``WORKDIR`` directory is defined as follows:
-      ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
+      ::
+
+         ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
+
       The actual directory depends on several things:
-   
+
       -  TMPDIR
          : The top-level build output directory
       -  MULTIMACH_TARGET_SYS
@@ -7916,21 +8876,24 @@ system and gives an overview of their function and contents.
          : The recipe version
       -  PR
          : The recipe revision
-   
+
       As an example, assume a Source Directory top-level folder name
       ``poky``, a default Build Directory at ``poky/build``, and a
       ``qemux86-poky-linux`` machine target system. Furthermore, suppose
       your recipe is named ``foo_1.3.0-r0.bb``. In this case, the work
       directory the build system uses to build the package would be as
-      follows: poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
-   
+      follows:
+      ::
+
+         poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+
    XSERVER
       Specifies the packages that should be installed to provide an X
       server and drivers for the current machine, assuming your image
       directly includes ``packagegroup-core-x11-xserver`` or, perhaps
       indirectly, includes "x11-base" in
       :term:`IMAGE_FEATURES`.
-   
+
       The default value of ``XSERVER``, if not specified in the machine
       configuration, is "xserver-xorg xf86-video-fbdev xf86-input-evdev".
    
diff --git a/documentation/ref-manual/ref-varlocality.rst b/documentation/ref-manual/ref-varlocality.rst
index a130945718..a95504b571 100644
--- a/documentation/ref-manual/ref-varlocality.rst
+++ b/documentation/ref-manual/ref-varlocality.rst
@@ -25,23 +25,23 @@ Distribution (Distro)
 This section lists variables whose configuration context is the
 distribution, or distro.
 
--  ``DISTRO``
+-  :term:`DISTRO`
 
--  ``DISTRO_NAME``
+-  :term:`DISTRO_NAME`
 
--  ``DISTRO_VERSION``
+-  :term:`DISTRO_VERSION`
 
--  ``MAINTAINER``
+-  :term:`MAINTAINER`
 
--  ``PACKAGE_CLASSES``
+-  :term:`PACKAGE_CLASSES`
 
--  ``TARGET_OS``
+-  :term:`TARGET_OS`
 
--  ``TARGET_FPU``
+-  :term:`TARGET_FPU`
 
--  ``TCMODE``
+-  :term:`TCMODE`
 
--  ``TCLIBC``
+-  :term:`TCLIBC`
 
 .. _ref-varlocality-config-machine:
 
@@ -50,23 +50,23 @@ Machine
 
 This section lists variables whose configuration context is the machine.
 
--  ``TARGET_ARCH``
+-  :term:`TARGET_ARCH`
 
--  ``SERIAL_CONSOLES``
+-  :term:`SERIAL_CONSOLES`
 
--  ``PACKAGE_EXTRA_ARCHS``
+-  :term:`PACKAGE_EXTRA_ARCHS`
 
--  ``IMAGE_FSTYPES``
+-  :term:`IMAGE_FSTYPES`
 
--  ``MACHINE_FEATURES``
+-  :term:`MACHINE_FEATURES`
 
--  ``MACHINE_EXTRA_RDEPENDS``
+-  :term:`MACHINE_EXTRA_RDEPENDS`
 
--  ``MACHINE_EXTRA_RRECOMMENDS``
+-  :term:`MACHINE_EXTRA_RRECOMMENDS`
 
--  ``MACHINE_ESSENTIAL_EXTRA_RDEPENDS``
+-  :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
 
--  ``MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS``
+-  :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
 
 .. _ref-varlocality-config-local:
 
@@ -76,23 +76,23 @@ Local
 This section lists variables whose configuration context is the local
 configuration through the ``local.conf`` file.
 
--  ``DISTRO``
+-  :term:`DISTRO`
 
--  ``MACHINE``
+-  :term:`MACHINE`
 
--  ``DL_DIR``
+-  :term:`DL_DIR`
 
--  ``BBFILES``
+-  :term:`BBFILES`
 
--  ``EXTRA_IMAGE_FEATURES``
+-  :term:`EXTRA_IMAGE_FEATURES`
 
--  ``PACKAGE_CLASSES``
+-  :term:`PACKAGE_CLASSES`
 
--  ``BB_NUMBER_THREADS``
+-  :term:`BB_NUMBER_THREADS`
 
--  ``BBINCLUDELOGS``
+-  :term:`BBINCLUDELOGS`
 
--  ``ENABLE_BINARY_LOCALE_GENERATION``
+-  :term:`ENABLE_BINARY_LOCALE_GENERATION`
 
 .. _ref-varlocality-recipes:
 
@@ -109,11 +109,11 @@ Required
 
 This section lists variables that are required for recipes.
 
--  ``LICENSE``
+-  :term:`LICENSE`
 
--  ``LIC_FILES_CHKSUM``
+-  :term:`LIC_FILES_CHKSUM`
 
--  ``SRC_URI`` - used in recipes that fetch local or remote files.
+-  :term:`SRC_URI` - used in recipes that fetch local or remote files.
 
 .. _ref-varlocality-recipe-dependencies:
 
@@ -122,15 +122,15 @@ Dependencies
 
 This section lists variables that define recipe dependencies.
 
--  ``DEPENDS``
+-  :term:`DEPENDS`
 
--  ``RDEPENDS``
+-  :term:`RDEPENDS`
 
--  ``RRECOMMENDS``
+-  :term:`RRECOMMENDS`
 
--  ``RCONFLICTS``
+-  :term:`RCONFLICTS`
 
--  ``RREPLACES``
+-  :term:`RREPLACES`
 
 .. _ref-varlocality-recipe-paths:
 
@@ -139,11 +139,11 @@ Paths
 
 This section lists variables that define recipe paths.
 
--  ``WORKDIR``
+-  :term:`WORKDIR`
 
--  ``S``
+-  :term:`S`
 
--  ``FILES``
+-  :term:`FILES`
 
 .. _ref-varlocality-recipe-build:
 
@@ -153,14 +153,14 @@ Extra Build Information
 This section lists variables that define extra build information for
 recipes.
 
--  ``DEFAULT_PREFERENCE``
+-  :term:`DEFAULT_PREFERENCE`
 
--  ``EXTRA_OECMAKE``
+-  :term:`EXTRA_OECMAKE`
 
--  ``EXTRA_OECONF``
+-  :term:`EXTRA_OECONF`
 
--  ``EXTRA_OEMAKE``
+-  :term:`EXTRA_OEMAKE`
 
--  ``PACKAGECONFIG_CONFARGS``
+-  :term:`PACKAGECONFIG_CONFARGS`
 
--  ``PACKAGES``
+-  :term:`PACKAGES`
diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst
index c5ddcca97f..2b82b79102 100644
--- a/documentation/ref-manual/resources.rst
+++ b/documentation/ref-manual/resources.rst
@@ -23,8 +23,7 @@ The Yocto Project gladly accepts contributions. You can submit changes
 to the project either by creating and sending pull requests, or by
 submitting patches through email. For information on how to do both as
 well as information on how to identify the maintainer for each area of
-code, see the "`Submitting a Change to the Yocto
-Project <&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change>`__" section in the
+code, see the ":ref:`how-to-submit-a-change`" section in the
 Yocto Project Development Tasks Manual.
 
 .. _resources-bugtracker:
@@ -48,8 +47,7 @@ A general procedure and guidelines exist for when you use Bugzilla to
 submit a bug. For information on how to use Bugzilla to submit a bug
 against the Yocto Project, see the following:
 
--  The "`Submitting a Defect Against the Yocto
-   Project <&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project>`__"
+-  The ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`"
    section in the Yocto Project Development Tasks Manual.
 
 -  The Yocto Project :yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
@@ -67,22 +65,22 @@ and announcements. To subscribe to one of the following mailing lists,
 click on the appropriate URL in the following list and follow the
 instructions:
 
--  ` <&YOCTO_LISTS_URL;/listinfo/yocto>`__ - General Yocto Project
+-  https://lists.yoctoproject.org/g/yocto - General Yocto Project
    discussion mailing list.
 
--  ` <&OE_LISTS_URL;/listinfo/openembedded-core>`__ - Discussion mailing
+-  https://lists.openembedded.org/g/openembedded-core - Discussion mailing
    list about OpenEmbedded-Core (the core metadata).
 
--  ` <&OE_LISTS_URL;/listinfo/openembedded-devel>`__ - Discussion
+-  https://lists.openembedded.org/g/openembedded-devel - Discussion
    mailing list about OpenEmbedded.
 
--  ` <&OE_LISTS_URL;/listinfo/bitbake-devel>`__ - Discussion mailing
+-  https://lists.openembedded.org/g/bitbake-devel - Discussion mailing
    list about the :term:`BitBake` build tool.
 
--  ` <&YOCTO_LISTS_URL;/listinfo/poky>`__ - Discussion mailing list
+-  https://lists.yoctoproject.org/g/poky - Discussion mailing list
    about `Poky <#poky>`__.
 
--  ` <&YOCTO_LISTS_URL;/listinfo/yocto-announce>`__ - Mailing list to
+-  https://lists.yoctoproject.org/g/yocto-announce - Mailing list to
    receive official Yocto Project release and milestone announcements.
 
 For more Yocto Project-related mailing lists, see the
@@ -115,7 +113,7 @@ Here is a list of resources you might find helpful:
    planning, release engineering, QA & automation, a reference site map,
    and other resources related to the Yocto Project.
 
--  `OpenEmbedded <&OE_HOME_URL;>`__\ *:* The build system used by the
+-  `OpenEmbedded <http://www.openembedded.org/>`__\ *:* The build system used by the
    Yocto Project. This project is the upstream, generic, embedded
    distribution from which the Yocto Project derives its build system
    (Poky) and to which it contributes.
@@ -127,53 +125,47 @@ Here is a list of resources you might find helpful:
    guide to the BitBake tool. If you want information on BitBake, see
    this manual.
 
--  `Yocto Project Quick Build <&YOCTO_DOCS_BRIEF_URL;>`__\ *:* This
+-  :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` *:* This
    short document lets you experience building an image using the Yocto
    Project without having to understand any concepts or details.
 
--  `Yocto Project Overview and Concepts
-   Manual <&YOCTO_DOCS_OM_URL;>`__\ *:* This manual provides overview
+-  :doc:`../overview-manual/overview-manual` *:* This manual provides overview
    and conceptual information about the Yocto Project.
 
--  `Yocto Project Development Tasks
-   Manual <&YOCTO_DOCS_DEV_URL;>`__\ *:* This manual is a "how-to" guide
+-  :doc:`../dev-manual/dev-manual` *:* This manual is a "how-to" guide
    that presents procedures useful to both application and system
    developers who use the Yocto Project.
 
--  `Yocto Project Application Development and the Extensible Software
-   Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__\ *manual:* This
+-  :doc:`../sdk-manual/sdk-manual` *manual :* This
    guide provides information that lets you get going with the standard
    or extensible SDK. An SDK, with its cross-development toolchains,
    allows you to develop projects inside or outside of the Yocto Project
    environment.
 
--  `Yocto Project Board Support Package (BSP) Developer's
-   Guide <&YOCTO_DOCS_BSP_URL;>`__\ *:* This guide defines the structure
+-  :doc:`../bsp-guide/bsp` *:* This guide defines the structure
    for BSP components. Having a commonly understood structure encourages
    standardization.
 
--  `Yocto Project Linux Kernel Development
-   Manual <&YOCTO_DOCS_KERNEL_DEV_URL;>`__\ *:* This manual describes
+-  :doc:`../kernel-dev/kernel-dev` *:* This manual describes
    how to work with Linux Yocto kernels as well as provides a bit of
    conceptual information on the construction of the Yocto Linux kernel
    tree.
 
--  `Yocto Project Reference Manual <&YOCTO_DOCS_REF_URL;>`__\ *:* This
+-  :doc:`../ref-manual/ref-manual` *:* This
    manual provides reference material such as variable, task, and class
    descriptions.
 
--  `Yocto Project Mega-Manual <&YOCTO_DOCS_MM_URL;>`__\ *:* This manual
+-  `Yocto Project Mega-Manual <https://docs.yoctoproject.org/singleindex.html>`__\ *:* This manual
    is simply a single HTML file comprised of the bulk of the Yocto
    Project manuals. The Mega-Manual primarily exists as a vehicle by
    which you can easily search for phrases and terms used in the Yocto
    Project documentation set.
 
--  `Yocto Project Profiling and Tracing
-   Manual <&YOCTO_DOCS_PROF_URL;>`__\ *:* This manual presents a set of
+-  :doc:`../profile-manual/profile-manual` *:* This manual presents a set of
    common and generally useful tracing and profiling schemes along with
    their applications (as appropriate) to each tool.
 
--  `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__\ *:* This manual
+-  :doc:`../toaster-manual/toaster-manual` *:* This manual
    introduces and describes how to set up and use Toaster. Toaster is an
    Application Programming Interface (API) and web-based interface to
    the :term:`OpenEmbedded Build System`, which uses
@@ -188,7 +180,7 @@ Here is a list of resources you might find helpful:
    the Yocto Project website and click on the "RELEASE INFORMATION" link
    for the appropriate release.
 
--  `Bugzilla <&YOCTO_BUGZILLA_URL;>`__\ *:* The bug tracking application
+-  `Bugzilla <https://bugzilla.yoctoproject.org>`__\ *:* The bug tracking application
    the Yocto Project uses. If you find problems with the Yocto Project,
    you should report them using this application.